-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configuration Provider API #436
Comments
That API is specific to cpptools, so clangd extension will need its own API. It will also need to be supported by "configuration providers" including cmake-tools. Assuming that both cpptools and cmake-tools are now maintained by Microsoft, guess how likely it is to happen... VS Code docs don't even mention any alternative to cpptools. |
Of course, I didn't expect clangd to have the same API, but to replicate the general idea. I only created this issue to improve xmake-vscode, this extension already support cpptools and codelldb debugger, so I'm thinking to do the same for the C++ completion, with cpptools and clangd. Some users only use VSCodium, and cpptools cannot be installed in this IDE, so a combo of clangd/code-lldb could work. This can help to reduce the minimal amount of configuration. |
At the protocol level, clangd does support the client specifying compile commands via The part I'm less sure about is whether another vscode extension can just get its hands on the |
I made some test/research and actually this not possible to access to variables inside the extension. However I find how to expose an API: // clangd extension
const api = new API();
export async function activate(context: vscode.ExtensionContext) {
return api;
}
// other extension
const clangd = vscode.extensions.getExtension("llvm-vs-code-extensions.vscode-clangd");
if (clangd) {
let extension = undefined;
if (!clangd.isActive) {
extension = await cpptools.activate();
} else {
extension = clangd.exports;
}
const api = extension;
} It's based on cpptools activation and cpptools npm package |
Thanks for checking. Are you interested in writing a patch that implements the desired API? |
Of course I can do it, but I have no idea when it will be ready. |
This would be useful for bazel integration. Currently we generate a large compile commands file for our whole repository, but requesting this information on demand for individual files would be nice for performance. Generating the compile commands uses a separate command rather than as part of the build, so this has to be manually re-run when something that affects the compile commands changes. Possibly if the editor requested this it would be easier to keep up-to-date, although exactly when the editor re-requests this is presumably an open question. |
Another possible direction would be to use the build server protocol. If a BSP connection file exists and supports cpp, this extension could launch a BSP, get the target for the currently-open file, gather the compiler flags etc, and send this to clangd. Or, clangd could support this natively: clangd/clangd#1903 |
@HighCommander4 another issue here I'm interested in tackling 😅 Context: at work we have a massive C++ bazel monorepo, which leads to two issues:
I suspect this is actually the indexer doing this, but regardless compile_commands.json is simply not a scalable approach to massive monorepos. We need to plug clangd directly into getting compile commands. |
The reason I bring this up now is that buck2 and rust-analyzer have created a good integration: |
We're running big repos too in my organization, including bazel based setups. With some scripting and talks with architects we were able to narrow down a few rules as to how the project is structured, which allows us to build our own heuristic based configuration setup which we lunch on startup and it delivers 95% accuracy which works very well for most of our users. The rest can be tweaked with repo persistent project configuration, or included in build system to access One thing which we concluded in our jorney is that generating a series of .clangd files on a "module" basis yields much better experience than working with compile_commands.json. It's better for new files, it's better for test files, it's much smaller so we don't need clangd to spend the first 5-8s just reading the file for the first time. We basically went from 300k lines compile_commands.json to 300 lines "repo level" .clangd and 30-50 lines "module level" .clangd which gets generated dynamically. In any case, by not relying on bazel build to deliver compile_commands.json we managed to get down to 10s setup instead of 5 minutes, definitely worth it in scale. Chopping down compile_commands.json to see what's common across areas is an interesting excercise of itself, it could be used for security audits and activities around making sure we include (or not) certain compiler flags across the project, and/or we put good defaults in common locations |
Wow, thats a great insight! I'll 100% be trying this. I do still think long term it would be nice to create these integrations within vscode, bazel, and/or clangd. |
Following up on this earlier comment:
As of version 0.1.29, vscode-clangd now has an API that exposes the So, I think everything is now in place for other vscode extensions (e.g. a bazel one) to provide compile commands to clangd as an alternative to using |
The cpptools extension provide an API to consume a custom configuration provider.
For example the cmake-tools extension take advantage of that to have C++ completion without compile_commands file.
Could be possible to implement the same thing in vscode-clangd ?
The text was updated successfully, but these errors were encountered: