Restart IDE when external C/C++ file is opened in active editor leads to clangd compilation commands fallback #87
Comments
|
Sounds good. I don't know if you meant it this way, but I think each editor would have to keep the whole chain of files from where it was opened. Otherwise if one of the intermediate editors is closed before restarting, after restart the editor would not be able to find the next origin which is in the workspace. |
Yep, good point, and this info should be stored persistent. |
|
I had a quick look how to implement this. I think we'll have to make some changes in lsp4e. |
|
I provided a PR to LSP4E with a similar approach to support a LS per project. The PR was declined, because it was to LS specific. |
clangd has trouble on Windows machines to detect the system headers. Therefore we add the includes paths from the first project file opened by the LS client to the fallbackFlags. see https://clangd.llvm.org/extensions#compilation-commands LIMITATION: The include path detection by ICBuildConfiguration.getScannerInformation works currently only for the clang compiler. g++/gcc doesn't work. fixes eclipse-cdt#87
clangd has trouble on Windows machines to detect the system headers. Therefore we add the includes paths from the first project file opened by the LS client to the fallbackFlags. see https://clangd.llvm.org/extensions#compilation-commands LIMITATION: The include path detection by ICBuildConfiguration.getScannerInformation works currently only for the clang compiler. g++/gcc doesn't work. fixes eclipse-cdt#87
clangd has trouble on Windows machines to detect the system headers. Therefore we add the includes paths from the first project file opened by the LS client to the fallbackFlags. see https://clangd.llvm.org/extensions#compilation-commands LIMITATION: The include path detection by ICBuildConfiguration.getScannerInformation works currently only for the clang compiler. g++/gcc doesn't work. fixes eclipse-cdt#87
clangd has trouble on Windows machines to detect the system headers. Therefore we add the includes paths from the first project file opened by the LS client to the fallbackFlags. see https://clangd.llvm.org/extensions#compilation-commands LIMITATION: The include path detection by ICBuildConfiguration.getScannerInformation works currently only for the clang compiler. g++/gcc doesn't work. fixes eclipse-cdt#87
clangd has trouble on Windows machines to detect the system headers. Therefore we add the includes paths from the first project file opened by the LS client to the fallbackFlags. see https://clangd.llvm.org/extensions#compilation-commands LIMITATION: The include path detection by ICBuildConfiguration.getScannerInformation works currently only for the clang compiler. g++/gcc doesn't work. fixes #87
Uh oh!
There was an error while loading. Please reload this page.
When clangd cannot find a compile_commands.json the fallback values are used.
Solution proposal:
I assume that in most cases this external file has been opened by a hyperlink in the editor. During startup, the LS will be started, when the active editor is the LSP based C/C++ editor.
If the IDE keeps track of the origin file, the LS has to be started with this origin file, which must be a file in the current workspace. If the origin file is not a workspace file then get the origin of this file and so on until a project file (with a compile_commands.json) has been reached. When the LS server is started with the origin file, clangd will inherit the compile settings from the first opened file for the external file in focus.
The text was updated successfully, but these errors were encountered: