Allow pointing SourceFileConfigurationItem to a compile_commands.json file.

[micque01]

Feature Request

When implementing a CustomConfigurationProvider for intellisense, it would be good to be able to construct a SourceFileConfigurationItem from an existing compile_commands.json.

At Arm we're developing an extension where different files in a project could belong to different build "contexts" e.g. for a different target or compiler toolchain, so we need to be able to set different intellisense configurations depending on which file is being viewed.

Currently I am trying to parse out the command portion of the compile_commands.json to get the compiler args/fragments, and building up the compilerFragments list, but it would be so much better to point at compile_commands.json directly, similar to how it is being done in the c_cpp_properties.json config.

I hope this makes sense. If you have any alternative ideas on how to achieve this, it would be great to hear about it.

Thanks!

[bobbrow]

Thank you for the feature idea. We hadn't considered adding support to ingest the compile_commands.json through the configuration provider because we thought that if someone wanted to use that, they'd just set it themselves in c_cpp_properties.json.

If we exposed something like this, what would you need from the ConfigurationProvider API? Is the plan for your extension to call didChangeCustomConfiguration() when you want it to point to a different compile_commands.json file? We're currently looking at a potential update to the API to allow for providers to send all project configurations at once including for different contexts as you mention (e.g. Debug vs. Release, or maybe different targets as you mention) and we could consider accepting compile_commands.json as the source for any of these contexts.

Since this isn't available today, I think the closest thing to a workaround would be if you write to the C_Cpp.default.compileCommands setting (at the WorkspaceFolder level, not globally). You could effectively point it to the correct compile_commands.json file based on the active context in your extension. It's not a great solution and you would want to take special care only to set it if you are 100% sure the active workspace is using your extension, but I expect it would work - assuming your customers are not setting some other value for compileCommands in their c_cpp_properties.json files already.

EDIT: One drawback of the potential workaround is that if you do change the workspace folder settings, it will be written to the .vscode/settings.json file which may be under source control.

[micque01]

Hi Bob, thanks for the suggestions! We were thinking it would be helpful if there could be an attribute on SourceFileConfiguration which is the path to a compile commands file, and we would call didChangeCustomConfiguration whenever we want to have the configuration updated. We have multiple compile command files in the workspace sorted under different directories based on context, so it would be great to select one of these compile commands files dynamically.