[clang-tools-extra] Add --project-root to clangd (PR #155905)

Nathan Ridge via cfe-commits cfe-commits at lists.llvm.org
Fri Nov 28 23:05:07 PST 2025


HighCommander4 wrote:

> For multi-workspace (not vscode workspace) projects, say a monorepo where each subproject is built individually (and therefore separate build dirs and compile_commands.json), is the idea that each subproject will (should?) now have its own clangd instance running?

I would say this patch doesn't make any changes to how clangd works on, or should be used with, such projects.

This patch is adding (the beginnings of) a non-default mode of operation ("strong workspace mode") that users need to opt into. If you don't opt into it, everything will work just as it did before.

For a project of the sort you describe, even if you opt into "strong workspace mode" (and after the remaining behaviours described in [this comment](https://github.com/llvm/llvm-project/pull/155905#issuecomment-3549683238)) are implemented, not a lot is likely to change:
 * If you don't have a `compile_commands.json` file in your workspace's root directory, the new behaviour that clangd looks for such a file there even for files outside the workspace directory is basically a no-op. Clangd will continue using the sub-project `compile_commands.json` based on ancestor-directory lookup just as it did before.
 * Clangd will also look at a `.clangd` file in the workspace root, even for files outside the workspace directory. That might be convenient (you can stash some extra flags there that you want to apply for any file you open while working on this project), but shouldn't make a big difference.
 * The change to the working directory for fallback commands is probably not relevant if you have `compile_comands.json` files.

> is the idea that each subproject will (should?) now have its own clangd instance running?

It has separately been proposed that clients like vscode-clangd gain the ability to manager multiple clangd instances and launch one per "workspace root" (in the sense of vscode's multi-root workspaces). For example, one such proposal is being pursued in https://github.com/clangd/vscode-clangd/pull/810.

If such a proposal is accepted, then using it for a project of the sort you describe (i.e. making each sub-project a "workspace root") would be a separate knob you can opt into. I think it would come with both advantages and disadvantages. (For example, clangd's index would no longer be able to cross-reference symbols between sub-projects. Depending on how your sub-projects are related, this may be a desirable change or an undesirable one.)

If you do opt into such a hypothetical multi-root workspace feature, you could then _also_ opt into "strong workspace mode" for each sub-project, and that may bring more benefits than using "strong workspace mode" with a single workspace root for your overall project would have. (For example, if you have an ARM sub-project and an x86 sub-project, and you open a system header from a source file in your ARM sub-project, clangd will automatically use a compile command from one of your ARM source files, more reliably than it does today.)

https://github.com/llvm/llvm-project/pull/155905


More information about the cfe-commits mailing list