Am So., 14. Juni 2020 um 04:07 Uhr schrieb Jonah Graham <
...
As it turns out there are use cases behind just index support for the parser.
So please comment on how to design the methods for the parser to integrate it with CDT. I am appreciating any suggestions.
For now I found the following use cases:
1) Syntax highlighting/C-DOM-parser: For a given IFile, return the set of defines, include path to the DOM.
2) LSP. For a given IFile, return the path to the compiler executable and the set of command-line args that affect LSP (e.g. -m32, --sysroot). (This use-case is just a rough guess of mine).
(I assume you are referring to Language Server Protocol - I know earlier on there was another LSP acronym, but I can't recall what that was for.)
There is not much that I can tell about this.
3) End users often ask: Is compiler-option '-std=c17' (or similar) recognized and used for built-in detection? To aid users, these should be a way to provide a report on the options and detected include path and macros. (Otherwise we might get lots of questions).
I think this is a great idea. This is indeed a regular problem! This along with the better way of displaying is a good problem to solve.
I see two things here that users might want to see:
3a) A report on the effective include paths and macros for a given source file. This information can be retrieved by calling IScannerInfoProvider#getScannerInformation(IFile). So it does not affect the interface of the CompileCommandsJsonParser class.
3b) To answer the question "Is compiler-option '-std=cxx17' (or similar) recognized and used for built-in detection?", a new method on CompileCommandsJsonParser could be introduced which returns the compiler path and the arguments that affect built-in detection as a list of strings for a given file. Or it may return a list of file names along with the args used for built-in detection.
Concerning the end-user question, this is currently implemented by printing the command-line and output of built-in detection to a console. This was inspired by managed built but turns out to be wayy too complicated for users. They will have to enable the 'allocate console' option, force a new build ro be run and finally have to find the console. It could be much simpler if users can just click a 'show report' button and have a dialog/view opened.
We could get rid of the console printing if we implement 3b above. The console argument for the parser may then be removed, too.
Martin
