Intellisense fails if provider is ms-vscode.cmake-tools but cmake.buildDirectory is nonStandard

[atsju]

Bug type: Language Service

Describe the bug

• OS and Version: win 10 - 64
• VS Code Version:
  Version: 1.64.2 (user setup)
  Commit: f80445acd5a3dadef24aa209168452a3d97cc326
  Date: 2022-02-09T22:02:28.252Z
  Electron: 13.5.2
  Chromium: 91.0.4472.164
  Node.js: 14.16.0
  V8: 9.1.269.39-electron.0
  OS: Windows_NT x64 10.0.19043
• C/C++ Extension Version:v1.8.4
• Other extensions you installed (and if the issue persists after disabling them):
  cmake-tools: v1.9.2
• If using SSH remote, specify OS of remote machine:
• A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc).

When using provider ms-vscode.cmake-tools along with cmake.buildDirectory it seems that cpp tools become sunable to find the compile_commands.json file (see attached files for my configuration).
There is a workaround to copy compile_commands.json but then why do we have an automatic provider ?
You or cmake-tools need to fix the provider to beable to work together even when user uses specific path for build.

Steps to reproduce

1. Reset intellisense database
2. Close Vscode
3. Open Vscode
4. wait for Cmake-tools to configure project
5. wait for cpp tools intellisense analysis and parsing
6. got to a file and F12 on a function
7. Intellisense is failing to go to definition

Expected behavior

A working intellisense out of the box or an explicit error somewhere

Code sample and logs

• Code sample

• Configurations in c_cpp_properties.json

settings.json_WORKING.txt
settings.json_FAILING.txt

• Logs from running C/C++: Log Diagnostics from the VS Code command palette

When intellisense fails:
logDiag.txt

Note there are many missing path and defines

• Logs from the language server logging

langServerlogging.txt

Screenshots

Additional context

[bobbrow]

This appears to be an issue with CMake Tools. When the configurationProvider is set, you shouldn't need compile_commands.json at all.

I'm moving this over to that repository for us to troubleshoot a bit more. Can you also run the CMake: Log Diagnostics command and share the output with us?

One thing that stands out from your logs is that there is no configuration provided for the header files and I also didn't see any c/cpp files being tag parsed that looked like they might be related to the header file that was open. I haven't seen your CMakeLists.txt, but if you include the headers files in your SOURCES for the add_executable or add_library targets, CMake should add configurations for header files in addition to the cpp files (which compile_commands.json does not do). I'm not sure what's in the compile_commands.json that causes the header file to get configured properly, but maybe you can share the relevant part of that file for the working case (after running C/C++: Log Diagnostics to determine which c/cpp file is backing the header file for IntelliSense).

[atsju]

As requested CMake: Log Diagnostics for failing case:
logDiagCmake.txt

In our project, header files are not included in SOURCES. We use target_include_directories to link the headers. When using the workaround with compile_commands.json there is no explicit header file listed. I suppose it's working thanks to the multiple -Ifolder. As a side note, let me kindly remind this is an issue mainly about configuratioProvider and I'm not really interested in how it works. For me compile_commands.json is only a workaround.

Anyway, let me know if you need any more information to reproduce/fix this.

[atsju]

Pleas kindly try this simple repo which represents well our architecture and reproduces the issue.
https://github.com/atsju/cmakeDiamondDependency

[bobbrow]

Sorry, it doesn't repro for me with your example.

Your log confirms my suspicion though. You may not be interested in the details, but I document them here for other members of the team to avoid duplicating the investigation. cpptools asked for a configuration for app_data_logger_com.h, but we don't have it because the header is not listed in the SOURCES. Usually cpptools will detect a .c/.cpp that includes the header and ask us for that file instead, but for some reason CMake Tools sends and then clears out the list of paths to search for those source files so cpptools doesn't know about them.

It's possible that we've fixed this in our pending release though because we fixed a few problems with the configuration provider since 1.9.2 was released. If you would be willing to try it out, all you need to do is:

1. Open the extensions panel in VS Code
2. Select the CMake Tools extension
3. Click the "Switch to Pre-release Version" button

[atsju]

I just reproduces issue on a different computer with shared setup and I know several colleagues have same issue. We are using arm-none-eabi-gcc 10 2020-q4-major.

The pre-release version of cmake-tools you recommended seems to work better 👍

However, I get message from (I suppose) cpp-tools

[03/03/2022, 19:08:37] For C source files, IntelliSenseMode was changed from "windows-gcc-arm" to "windows-clang-x86" based on compiler args and querying compilerPath: "C:\Program Files\LLVM\bin\clang.exe"
[03/03/2022, 19:08:37] IntelliSenseMode was changed because it didn't match the detected compiler.  Consider setting "compilerPath" instead.  Set "compilerPath" to "" to disable detection of system includes and defines.
[03/03/2022, 19:08:37] For C++ source files, IntelliSenseMode was changed from "windows-gcc-arm" to "windows-clang-x86" based on compiler args and querying compilerPath: "C:\Program Files\LLVM\bin\clang.exe"
[03/03/2022, 19:08:37] IntelliSenseMode was changed because it didn't match the detected compiler.  Consider setting "compilerPath" instead.  Set "compilerPath" to "" to disable detection of system includes and defines.

the compiler does't seem to be detected correctly.

The message disappears if I set
"C_Cpp.default.compilerPath": "C:\\Program Files (x86)\\GNU Arm Embedded Toolchain\\10 2020-q4-major\\bin\\arm-none-eabi-gcc.exe",
However, isn't the this supposed to work automagically through configurationProvider?

As always, I'm happy to provide any needed information.

[bobbrow]

It is supposed to work automatically. Can you re-reun the CMake: Log Diagnostics command and share the output so we can see what it is sending to cpptools? I'd be curious to see if we're actually sending "C:\Program Files\LLVM\bin\clang.exe" and if so, just double checking which "Kit" is set on your side (in the status bar).

[atsju]

I did some more tests and I will divide on 2 computers because I feel like there is much to say. Let's try to keep thing organised.
Everything with pre-release 1.10.0

Workplace computer
kitsWorkplace.txt
Tested on real project (not the shared github)

1. If there is a variant in buildDirectory like in "cmake.buildDirectory": "${workspaceRoot}/build_${variant:PROJECT_SELECTOR}_${buildType}", then it won't work (never) WorkplaceFail.txt
   cmake-variants.yaml.txt

2. on this computer I don't get the warning from above comment.

3. My process is aways delete build* folder, clear Intellisense database, close vscode, open vscode, try, (here intellisense doesn't work). Then I close again, open again and this time it works
   workplaceOK.txt
   Reset Intellisense database, close, open and it still works so I suppose it's because build* folder already exists

Personal computer

Yes I double (or more) checked the selected kit

Here the log file and an additional one for information
logDiag.txt
kits.txt

Changing manually the order in kits to have clang second didn't change anything.

Problems about needing to reload VScode twice is same as describes above

I hope this will help.
To recap:

1. not working when using variants
2. need to load twice
3. compiler not passed correctly at first try might generate warning

[atsju]

Please allow me to add CPP-tools debug level log on first and second opening of the VScode. (first time failing and seconds passing) on personal computer and shared cmakeDiamondDependency git project. I hope this helps.

firstOpenFail.txt
secondOpenPass.txt

What I see is that even on success compiler goes back and forth between different versions.

[bobbrow]

Not sure what changed on my side, but I am now able to reproduce the problem. I have a fix.

[bobbrow]

This fix should be available in the 1.10.2 pre-release scheduled for tomorrow morning (7am PST, 3pm UTC)

[atsju]

Thank you for this fix. Everything seems to be OK now.