Strategy for opening external C/C++ (header) files

[ghentschke]

Currently the compile_comands.json used for external files (e.g. standard library headers) is inferred from a project file. Especially when using a hyperlink to a included library header file, the behavior of clangd is not always correct:

When there are files from more than one project opened in editors, the compilation database from the first opened file is used. This could be a file form a different project. Instead the compilation database from the file with the hyperlink should be used.

A solutions for this issue can become very complicated:
Two source files from different projects include the same standard lib header form the same source (URI is equal) but each project has different preprocessor options. Which compilation database should be used for this file in this case? Do the first one wins?

Is in the end the current solution where the first one wins correct?

[NormanMohrmannV]

The issue you mentioned with clangd using the compilation database from the first opened file can be a problem when working with multiple projects in the same editor. In the case of hyperlinking to included library header files, it would make sense for clangd to use the compilation database from the file with the hyperlink.

However, as you pointed out, determining which compilation database to use when multiple projects have the same source file with different preprocessor options can be a complicated issue. It may be necessary to prioritize one project over the other, or to provide some mechanism for the user to choose which compilation database to use.

Ultimately, the solution will depend on the specific use case and requirements. In cases where the first compilation database is used by default, it may be necessary for the user to manually specify a different compilation database for the file with the hyperlink.

[ghentschke]

Two source files from different projects include the same standard lib header form the same source (URI is equal) but each project has different preprocessor options. Which compilation database should be used for this file in this case? Do the first one wins?

IMO an appropriate solution could be, to establish a parent -> child dependency between the editor files.
e.g. main.cpp -> string -> bits/c++config.h
main.cpp is the root file and has a child string which has a child c++config.h.

This has to be implemented in LSP4E. At the moment a file/document is identified in LSP4E by the URI. This is not sufficient in case of same header files included in different projects or project files with different compilation settings. The root file (here main.cpp) must be used as an additional identifier to make the included file distinctive. Different editor tabs has to be opened for the same included file in different projects/root files.

The children shall infer the compilation database from the parent. It can be necessary to run a LS per project to get this behavior. This has to be checked.

The next step ist to make this parent/child dependency persistant. This is necessary when the IDE gets restarted while a system header file is in focus. After restart the LS has to be started for the opened system header. The LS need the information which compilation database to use for this file. Maybe clangd can use the cached index file in the project workspace folder.