Can CMake Tools disqualify candidates for Go to Reference that aren't in any source file groups?

[starball5]

My understanding is that CMake Tools provides info to cpptools, acting as a "configuration provider", which cpptools uses to provide features like Go to Reference. Currently, under a certain set of circumstances I don't fully understand, the combination of CMake Tools with cpptools (at least when using CMake Presets) identifies candidates for Go to Reference which are not in any source file group for the currently selected and configured CMake project, or reachable in the source file through #include-ed files. A repro for this is available here.

When I say "source file groups", I'm referring to the thing which CMake Tools receives from the CMake File API for target-build-config combos.

Is this something that CMake Tools / cpptools (or the combination of the two) could reasonably provide a better user experience for? Would there be any drawbacks to doing this, or considerations which make this infeasible or impractical?

[bobbrow]

It's feasible, but not with the current API that cpptools exports. Cpptools would need the whole project information up front, whereas we currently only ask for source files as they are needed for IntelliSense.

This is something we've been thinking about because in order to enable further codebase unification between VS and VS Code C++ implementations we'd need to treat the workspace more like a "project" and have all the configuration information in the database at the earliest point possible (like VS does) instead of "on demand" like we're currently doing in cpptools.

[starball5]

Thanks! Are you okay if I quote this in my answer post? (which is licensed under CC-BY-SA-4.0). Otherwise I'll paraphrase.

[bobbrow]

Paraphrase would be better in case I ever edit my comment. As I think about it more, we probably could do something inefficient and query for configs for all files in the workspace up front and build up our own understanding of a "project" this way, but it wouldn't have any idea about source file groups like you mentioned in the original post.

Also, please don't set any expectations that we're working on this right now, because we aren't and we also don't have an ETA for when this work would start.

[starball5]

Also, please don't set any expectations that we're working on this right now

Don't worry- I won't :)

For reference, the code I saw about file groups / source groups when skimming CMake Tools' codebase is lines like

vscode-cmake-tools/src/cpptools.ts

Line 478 in ddb8cda

const includePath = (fileGroup.includePath ? fileGroup.includePath.map(p => p.path) : target.includePath || []).concat(frameworkPaths);

,

vscode-cmake-tools/src/cpptools.ts

Line 605 in ddb8cda

const includePath = [...new Set(util.flatMap(grps, grp => grp.includePath || []))].map(item => item.path);

, https://github.com/microsoft/vscode-cmake-tools/blob/main/src/drivers/cmakeServerDriver.ts#L99, https://github.com/microsoft/vscode-cmake-tools/blob/main/src/drivers/cmakeFileApi.ts#L474. I didn't spend the time to understand what's going on. I was just poking around. I did see that in <binaryDir>.cmake/api/v1/reply/target-<target>-<config>-<hash>.json has a sources array.