bencefr
commented
1 year ago Great description @tortmayr , I was just about to write up something similar...
My team is also working on an extension that manages multi-root workspaces where multiple projects exists at the same time, all of them likely with multiple build folders. We track the active build ourselves, so we know which compile_commands.json database should be active at any given time. It would be greatly beneficial if by a single command we could tell the clangd extension to change context.
However... it's not always the case that a compilation database helps, as that is generated after the fact, not while developing. When a new file is added, when code moves around, it is just silly to start a build to regenerate the compilation database. How we interact with Microsoft's C/C++ extension is via providers where we translate the compilation database to their expected configuration objects for any given file (even if it's not found in the database just yet) with fallbacks. I believe this is a bit more complex but rather flexible alternative solution.
planger
HighCommander4
MNASTM
geertj
For many C/C++ based Editors it is a common practice to work on several projects within the same workspace simultaneously (e.g. Eclipse CDT). Unfortunately this usecase is currently not well supported when using (vscode-)clangd.
Clangd has no explicit support for mulit-root workspaces. It is possible to provide baseline multi-project support by setting up project-specific compilation databases, since clangd searches and uses the individual compile_commands.json file in the source directory path to determine the CBD. However, this approach has several drawbacks: Indexing problems occurs when functions with same signature has been defined in separate projects (see this Issue #38) The indexing problems also result in incorrect/unexpected results when using LSP features like
go to definitionDetermining the CDB for external header files comes into troubles when there are several project roots. (see discussion in this Issue #907)
In addition, this approach causes issues with functions that should be scoped to a specific project like “finding all references” or “Renaming” (see also this issue)
Other parties like the cdt-lsp team also have encountered similar problems.
We worked on a proof of concept implementation that solves the issues mentioned above by extending vscode-clangd to support multiple clangd servers within the same workspace: For each project we start a dedicated clangd server and map all files that can be matched to a specific project to its respective clangd server instance. This ensures that files within a project are correctly scoped within the boundaries of a single project, resolving all issues mentioned above. In addition, we track the currently active project. Tracking the currently active project (or rather its clangd server) ensures that extensions that want to communicate with the clangd server without a specific file context (e.g. the memory usage view) still work as expected. The active project can either be set manually by the user, or can be tracked automatically based on the last active file editor.
This multi-project feature is completely opt–in and can be activated via VS Code preferences. The default project resolution strategy is to map each workspace folder to one project. An extension mechanism is provided to support more complex project resolution strategies.
While this approach solves the issues mentioned above it also comes with additional challenges in regards to resource management. To mitigate the resource consumptionclangd server instances are spun up dynamically and disposed once they are no longer needed (i.e. there is no longer an open editor that needs that specific clangd server instance). If a lot of code is shared between projects, though, the overall memory footprint might become larger as each server maintains its own index of these shared source files. But this is a compromise we believe is worth taking in multi-project scenarios. Moreover, there are options to mitigate this issue e.g. by using external indexes for shared library code.
For our usecases this solution works really well and offers a more complete and correct multi-project support than what can currently be achieved with vscode-clangd.
In our opinion this is a feature that could be interesting for other parties of the clangd community as well. We are happy to contribute our implementation back to the vscode-clangd project. Therefore, we would like to get your feedback whether you’d be interested in this feature! Due to the opt-in approach it could be integrated into the main vscode-clangd project without affecting the current behavior.
Please let us know what you think! Your perspective on having this feature integrated in the main vscode-clangd project or any other thoughts on this approach is highly appreciated!