Start `clangd` when a file of any type is opened if `compile_commands.json` is in a parent directory

I’ve built a database for my project, which has .c, .h. and .S (assembly) files. When I open VSCode and navigate to a .c file, clangd is started and I can use commands like “Go to Symbol in Workspace” just fine, even if I navigate to other files like a .S file.

However, if I close VSCode while in a .S file (or any file that’s not a.c or .h file, like a Makefile), then reopen VSCode, I start in the last file I opened, and because it’s not a .c or .h file clangd isn’t started, and I can’t use any clangd features until I open a .c or .h file, which is inconvenient.

Can we add an option to start clangd when any file is opened, as long as there’s a compile_commands.json in some parent directory?

[njames93]

That sounds like a solid plan, but I’d extend it to also look for the fallback CompileFlags.txt

[gsingh93]

I’d find this behavior useful with or without strong workspace mode.

It seems like clangd needs to receive at least one textDocument/didOpen before it loads the index (see https://github.com/microsoft/language-server-protocol/issues/861 and https://discourse.llvm.org/t/clangd-explicit-and-implicit-doc-open/205).

While ideally I think this could be improved in clangd, I think it would be worth it to implement a small workaround in vscode-clangd to get the desired behavior. One idea is that if we detect a compile_commands.json, we can just send that to clangd in a textDocument/didOpen request. clangd will load the index regardless of whether the file we sent is a valid C++ file. I fully support putting this behind a setting that’s off by default.

I did a quick test of this by adding {scheme: 'file', language: 'json'} in clangdDocumentSelector in clangd-context.ts. After opening the compile_commands.json, I was able to find symbols in other C files in the index. This was just a test of course, we shouldn’t be modifying clangdDocumentSelector but instead locating the compile_commands.json and sending it directly.

@sam-mccall Does this solution seem acceptable or too much of a hack?