vis4rd
commented
4 months ago Open vis4rd opened 4 months ago
vis4rd
commented
4 months ago vis4rd
commented
4 months ago I will also include screenshot of CMake Tools configuration UI and generated by CMake compile_commands.json as it seems relevant.
sean-mcmanus
commented
4 months ago @vis4rd What do you get when you run S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\bin\g++.exe -O3 -std=c++20 -m64 -Wp,-v -E -dM -x c++ nul. The clang-tidy error seems like it's caused by "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\VC\TOOLS\MSVC\14.33.31629\ATLMFC\INCLUDE", "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\VC\TOOLS\MSVC\14.33.31629\INCLUDE" not being in your includePath...it seems like that should be output by your compiler as an includePath? It's possible those includePaths might be getting added from the system environment variables.
vis4rd
commented
4 months ago @sean-mcmanus
I wonder why these MSVC include paths are taken into account...
When I click on the source of the error:
... I get to the cassert header itself, but from MSVC:
And there when I click on <assert.h>, I am being taken to assert.h from the correct compiler:
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\bin\g++.exe -O3 -std=c++20 -m64 -Wp,-v -E -dM -x c++ nul : vis4rd
commented
4 months ago It's possible those includePaths might be getting added from the system environment variables.
I double checked system PATH and user PATH, I don't see anything added from Visual Studio 2022 compiler.
system:
user:
But curiously CMake Tools "Scan for kits" command finds it anyway:
I have no idea how it finds MSVC... And why its include path taken into account even though I choose a different compiler. Maybe I will try to set up some minimal reproducible example.
vis4rd
commented
4 months ago Okay I pinned it down to the following setup:
main.cpp:#include <iostream>
int main() {
std::cout << "Hello, World!" << std::endl;
return 0;
}CMakeLists.txt:cmake_minimum_required(VERSION 3.11)
project(cpptools_repro LANGUAGES CXX)
add_executable(cpptools_repro main.cpp)... configure and build using CMake.
.vscode/settings.json in workspace root:{
"C_Cpp.intelliSenseEngine": "default",
"C_Cpp.intelliSenseCachePath": "${workspaceFolder}/.cache/vscode-cpptools",
"C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools",
"C_Cpp.loggingLevel": "Debug",
// "C_Cpp.codeAnalysis.clangTidy.enabled": true,
// "C_Cpp.codeAnalysis.clangTidy.useBuildPath": true,
}... and observe no errors in main.cpp
main.cpp and observe the following erros:And now to fix those errors, comment clang-tidy settings, remove .cache in workspace root and reload window.
Additionally, when I specify C_Cpp.codeAnalysis.clangTidy.path explicitly to the one matching the compiler (in this instance in S:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/bin/), the error disappears as it uses correct include paths, apparently. So it's a matter of wrong clang-tidy binary being used.
I think to fix this, it would require additional integration between CMakeTools and CppTools. Let's say I would like to achieve something like this:
"C_Cpp.codeAnalysis.clangTidy.enabled": true,
"C_Cpp.codeAnalysis.clangTidy.useBuildPath": true,
"C_Cpp.default.compileCommands": "${config:cmake.buildDirectory}/compile_commands.json",
"C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools",
"C_Cpp.intelliSenseEngine": "default",Current behavior: clang-tidy binary being used is the one shipped with CppTools.
Expected behavior: clang-tidy binary is taken from configurationProvider.
Expected behavior could be achieved in two forms:
configurationProvider binary path and chooses it over default shipped one.${config:cmake.compilerDirectory}, which then could be passed to C_Cpp.codeAnalysis.clangTidy.path.Do you think any of these approaches could be implemented?
Colengms
commented
3 months ago Hi @vis4rd . The reason MSVC headers are being indexed is that it's effectively still part of your configuration. The C/C++ Extension will detect a 'default' compiler if compilerPath is not specified (which your configuration does not). That compiler's information is then used for any file for which a configuration is not successfully provided by CMake Tools (perhaps not referred to in a CMakeLists.txt), and not found in your compile_commands.json (since you have that configured also). You can prevent this by setting "compilerPath": "", but then any file not otherwise configured would almost definitely not have working IntelliSense.
Setting "C_Cpp.codeAnalysis.clangTidy.useBuildPath": true makes the C/C++ Extension pass a configuration from compile_commands.json to clang-tidy instead of the configuration used to configure IntelliSense (which likely came from CMake Tools).
So, what I think you're seeing here is most likely an issue with the configuration provided by CMake Tools. Could you repro the issue again and provide the output of C/C++: Log Diagnostics (while the repro'ing file is open)? That should indicate exactly what configuration was provided by CMake Tools. (Alternatively, you could set "C_Cpp.loggingLevel": "Debug" and monitor the C/C++ output channel for a message related to receiving a custom configuration). The issue may be apparent by comparing the custom configuration CMake Tools provides with the contents of compile_commands.json for that same file. If this is what's happening, once we have more details, we could transfer this issue to the vscode-cmake-tools repo.
vis4rd
commented
3 months ago Hi @Colengms, I collected C/C++: Log Diagnostics:
-------- Diagnostics - 7/31/2024, 8:23:55 PM
Version: 1.21.3
Current Configuration:
{
"name": "Win32",
"includePath": [
"s:/Code/CPP/cpptools_repro/**"
],
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE"
],
"compilerPath": "cl.exe",
"cStandard": "c17",
"cppStandard": "c++17",
"intelliSenseMode": "windows-msvc-x64",
"compilerPathInCppPropertiesJson": "cl.exe",
"intelliSenseModeIsExplicit": false,
"cStandardIsExplicit": false,
"cppStandardIsExplicit": false,
"mergeConfigurations": false,
"compilerPathIsExplicit": false,
"configurationProvider": "ms-vscode.cmake-tools",
"browse": {
"path": [
"s:/Code/CPP/cpptools_repro/**",
"${workspaceFolder}"
],
"limitSymbolsToIncludedHeaders": true
}
}
Custom browse configuration:
{
"browsePath": [
"s:/code/cpp/cpptools_repro"
],
"compilerPath": "s:/environment/compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/bin/g++.exe",
"compilerArgs": [],
"compilerFragments": [
"-g"
]
}
cpptools version (native): 1.21.3.0
Translation Unit Mappings:
[ S:\Code\CPP\cpptools_repro\main.cpp - source TU]:
Translation Unit Configurations:
[ S:\Code\CPP\cpptools_repro\main.cpp ]:
Process ID: 10304
Memory Usage: 120 MB
Compiler Path: S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\bin\g++.exe
Includes:
System Includes:
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\include\c++\13.1.0
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\include\c++\13.1.0\x86_64-w64-mingw32
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\include\c++\13.1.0\backward
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\lib\gcc\x86_64-w64-mingw32\13.1.0\include
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\include
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\lib\gcc\x86_64-w64-mingw32\13.1.0\include-fixed
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\x86_64-w64-mingw32\include
Standard Version: c++17
IntelliSense Mode: windows-gcc-x64
Other Flags:
--g++
--gnu_version=130100
Total Memory Usage: 120 MB
------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 3105This is with settings.json:
{
"C_Cpp.intelliSenseEngine": "default",
"C_Cpp.intelliSenseCachePath": "${workspaceFolder}/.cache/vscode-cpptools",
"C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools",
"C_Cpp.loggingLevel": "Debug",
"C_Cpp.codeAnalysis.clangTidy.enabled": true,
"C_Cpp.codeAnalysis.clangTidy.useBuildPath": true,
}compile_commands.json:
[
{
"directory": "S:/Code/CPP/cpptools_repro/build",
"command": "S:\\Environment\\Compilers\\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\\bin\\g++.exe -g -o CMakeFiles\\cpptools_repro.dir\\main.cpp.obj -c S:\\Code\\CPP\\cpptools_repro\\main.cpp",
"file": "S:/Code/CPP/cpptools_repro/main.cpp",
"output": "CMakeFiles/cpptools_repro.dir/main.cpp.obj"
}
]Also tried without "C_Cpp.codeAnalysis.clangTidy.useBuildPath": true, the only difference in diagnostics is added line at the end:
Number of files parsed: 340So my guess is cl.exe should not be present in Current Configuration and possibly intelliSenseMode is also incorrect. But I think Custom browse configuration is correct since I built main.cpp with the following CMake Tools configuration:
Colengms
commented
3 months ago Hi @vis4rd
So my guess is cl.exe should not be present in Current Configuration
As I mentioned, cl.exe is part of your current configuration. If you'd prefer a compiler is not detected (and its system headers indexed) for configuring IntelliSense for files (not main.cpp) that are not otherwise configured by your custom configuration provider or compile_commands.json, you could explicitly set your compilerPath to "" in c_cpp_properties.json.
Indexing of headers is not directly related to IntelliSense for a specific file. All headers that might be referenced across the workspace will get indexed, not just those for files you open. Due to how IntelliSense configurations are determined per-file when using a custom configuration provider or compile_commands.json, you may see system headers from multiple compilers get indexed.
clang-diagnostic-error
This type of error is coming from clang-tidy (used by code analysis features), so that error would appear to be with how clang-tidy is being invoked (compiler arguments passed to it), which should be based off of your IntelliSense configuration for that file. "C_Cpp.codeAnalysis.clangTidy.useBuildPath": true simply causes the compile_commands.json entry to be used to generate that clang-tidy command line instead of the configuration provided by a custom configuration provider. Since I don't see any difference between the configuration of the source file (from your log diagnostics) and the compile_commands.json entry you've provided, it's still unclear to me why "C_Cpp.codeAnalysis.clangTidy.useBuildPath": true would alter that clang-tidy command line. Could you check the log output for the specific command lines passed to clang-tidy, with and without "C_Cpp.codeAnalysis.clangTidy.useBuildPath": true? (Or, perhaps if you weren't aware of how clang-tidy is being invoked, and perhaps that error appeared to be avoided because a code analysis run did not yet get triggered?)
vis4rd
commented
3 months ago Hi @Colengms thank you for quick response and detailed explanation, yet I still don't understand why my current configuration chooses cl.exe (I suppose it's MSVC compiler from Visual Studio 2022) when it's not specified anywhere. On the contrary, S:\\Environment\\Compilers\\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\\bin\\g++.exe is found by CMake Tools and chosen by me explicitly, when configuring through UI.
Due to how IntelliSense configurations are determined per-file when using a custom configuration provider or compile_commands.json, you may see system headers from multiple compilers get indexed.
I am also confused by this part. Some headers from different compilers are clearly incompatible with each other, as it's visible in this issue. Shouldn't only the headers from configuration provider be selected? Or "indexed" does not necesarily mean used in meaningful way? Edit: I don't think it's a matter of compiler, but clang-tidy binary.
"C_Cpp.codeAnalysis.clangTidy.useBuildPath": true simply causes the compile_commands.json entry to be used to generate that clang-tidy command line instead of the configuration provided by a custom configuration provider.
Just to be clear I should point out that issue is visible regardless of this parameter being set or not. Which is understandable, since as you also pointed out, there is no difference in compile_commands.json and Custom browse configuration (or Translation Unit Configuration).
(...), you could explicitly set your compilerPath to "" in c_cpp_properties.json
I have set it in settings.json, issue is still visible. I tried with the following c_cpp_properties.json:
{
"configurations": [
{
"name": "Win32",
"includePath": [
"${workspaceFolder}/**"
],
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE"
],
"cStandard": "c17",
"cppStandard": "c++17",
"intelliSenseMode": "windows-gcc-x64",
"configurationProvider": "ms-vscode.cmake-tools",
"compilerPath": ""
}
],
"version": 4
}... and settings.json:
{
"C_Cpp.intelliSenseEngine": "default",
"C_Cpp.intelliSenseCachePath": "${workspaceFolder}/.cache/vscode-cpptools",
"C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools",
"C_Cpp.loggingLevel": "Debug",
"C_Cpp.codeAnalysis.clangTidy.enabled": true,
"C_Cpp.default.compilerPath": ""
}And C/C++ diagnostics are as follows:
-------- Diagnostics - 7/31/2024, 9:38:59 PM
Version: 1.21.3
Current Configuration:
{
"name": "Win32",
"includePath": [
"s:/Code/CPP/cpptools_repro/**"
],
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE"
],
"cStandard": "c17",
"cppStandard": "c++17",
"intelliSenseMode": "windows-gcc-x64",
"configurationProvider": "ms-vscode.cmake-tools",
"compilerPath": "",
"compilerPathIsExplicit": true,
"cStandardIsExplicit": true,
"cppStandardIsExplicit": true,
"intelliSenseModeIsExplicit": true,
"compilerPathInCppPropertiesJson": "",
"configurationProviderInCppPropertiesJson": "ms-vscode.cmake-tools",
"mergeConfigurations": false,
"browse": {
"path": [
"s:/Code/CPP/cpptools_repro/**",
"${workspaceFolder}"
],
"limitSymbolsToIncludedHeaders": true
}
}
Custom browse configuration:
{
"browsePath": [
"s:/code/cpp/cpptools_repro"
],
"compilerPath": "s:/environment/compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/bin/g++.exe",
"compilerArgs": [],
"compilerFragments": [
"-g"
]
}
cpptools version (native): 1.21.3.0
Translation Unit Mappings:
[ S:\Code\CPP\cpptools_repro\main.cpp - source TU]:
Translation Unit Configurations:
[ S:\Code\CPP\cpptools_repro\main.cpp ]:
Process ID: 13496
Memory Usage: 120 MB
Compiler Path: S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\bin\g++.exe
Includes:
System Includes:
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\include\c++\13.1.0
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\include\c++\13.1.0\x86_64-w64-mingw32
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\include\c++\13.1.0\backward
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\lib\gcc\x86_64-w64-mingw32\13.1.0\include
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\include
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\lib\gcc\x86_64-w64-mingw32\13.1.0\include-fixed
S:\Environment\Compilers\mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt\x86_64-w64-mingw32\include
Standard Version: c++17
IntelliSense Mode: windows-gcc-x64
Other Flags:
--g++
--gnu_version=130100
Total Memory Usage: 120 MB
------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 3063Issue is still present.
I found the exact clang-tidy command in C/C++ output:
c:\Users\visard\.vscode\extensions\ms-vscode.cpptools-1.21.3-win32-x64/bin/../LLVM/bin/clang-tidy.exe
--header-filter=(S:/Code/CPP/cpptools_repro|S:\\Code\\CPP\\cpptools_repro)
--export-fixes=C:\Users\visard\AppData\Local\Temp\{108430223366751484}\fixes5488.yaml
--quiet
--use-color=false
S:/Code/CPP/cpptools_repro/main.cpp
<a lot of defined macros and variables>
-isystemS:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/include/c++/13.1.0
-isystemS:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/include/c++/13.1.0/x86_64-w64-mingw32
-isystemS:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/include/c++/13.1.0/backward
-isystemS:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/lib/gcc/x86_64-w64-mingw32/13.1.0/include
-isystemS:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/include
-isystemS:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/lib/gcc/x86_64-w64-mingw32/13.1.0/include-fixed
-isystemS:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/x86_64-w64-mingw32/includeI still think that clang-tidy.exe shipped with the extension is not compatible with selected configuration from configuration provider (like I mentioned in https://github.com/microsoft/vscode-cpptools/issues/12516#issuecomment-2253332327):
Additionally, when I specify C_Cpp.codeAnalysis.clangTidy.path explicitly to the one matching the compiler (in this instance in S:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/bin/), the error disappears as it uses correct include paths, apparently. So it's a matter of wrong clang-tidy binary being used.
Is there a way to avoid explicitly setting clang-tidy path, but to make it choose the one matching compiler (and include paths) from configuration provider?
Colengms
commented
3 months ago I still don't understand why my current configuration chooses cl.exe
Perhaps we're having a miscommunication about the term "current configuration". If you're referring to the configuration of IntelliSense for a specific file, then no, cl.exe is not chosen. However, regardless of what file you have open, having not specified any value at all for compilerPath, a default will be chosen/detected, which will only be used to configure IntelliSense for files that are not otherwise configured by CMake Tools or a compile_commands.json. For example, if you create a test.c file that is not referred to in your CMakeList.txt, the default compiler (cl.exe) would be used to configure IntelliSense for that file. However, IntelliSense and 'indexing' of file contents into the tag parsing database, are not the same thing. You will see files tag parsed into your database for your default/detected compiler, regardless of whether those files are referenced by source files you open. I'm not sure how to better explain it.
Note that any error referring to clang-diagnostic-error, while it may involve a 'squiggle', is NOT an IntelliSense error. It's a code analysis error, coming from clang-tidy, not coming from the IntelliSense engine. The same configuration used for IntelliSense should get used to compose the command line passed to clang-tidy. If there is an issue here, it would appear to be with the command line passed to clang-tidy.
@sean-mcmanus Could you take a look at the command line getting passed to clang-tidy?
vis4rd
commented
3 months ago Accidentally I pasted only a part of the clang-tidy command from C/C++ output (I updated my previous comment to include -isystem flags), but include paths are the same whether I set the clang-tidy binary explicitly or not. The only differences in output are displayed errors (and used binaries, of course):
Error while processing S:\Code\CPP\cpptools_repro\main.cpp.
warning: redefining builtin macro [clang-diagnostic-builtin-macro-redefined]
S:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/include/c++/13.1.0\bits/std_abs.h:136:3: error: __float128 is not supported on this target [clang-diagnostic-error]
136 | __float128
| ^
S:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/include/c++/13.1.0\bits/std_abs.h:137:7: error: __float128 is not supported on this target [clang-diagnostic-error]
137 | abs(__float128 __x)
| ^
S:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/include/c++/13.1.0\bits/stl_algobase.h:1057:21: error: __float128 is not supported on this target [clang-diagnostic-error]
1057 | __size_to_integer(__float128 __n) { return (long long)__n; }
| ^
S:/Environment/Compilers/mingw64_11.0.0_gcc_13.1.0_clang_16.0.5_msvcrt/include/c++/13.1.0\type_traits:494:39: error: __float128 is not supported on this target [clang-diagnostic-error]
494 | struct __is_floating_point_helper<__float128>
| ^
LSP: (received) cpptools/getCodeActions: file:///s%3A/Code/CPP/cpptools_repro/main.cpp (id: 59)
LSP: (invoked) cpptools/getCodeActions: file:///s%3A/Code/CPP/cpptools_repro/main.cpp (id: 59)
LSP: Sending response (id: 59)This may be a duplicate of: https://github.com/microsoft/vscode-cpptools/issues/9198
clang itself, and thus clang-tidy, doesn't support __float128, so it's necessary to work around the issue. Fully fixing this would seem to require clang to add support for __float128.
Environment
v1.21.3Bug Summary and Steps to Reproduce
Bug Summary: Cpp Tools indexes MSVC compiler from Visual Studio 2022 even though it is not specified anywhere in configuration, resulting in multiple errors like below:
Steps to reproduce:
Expected behavior: Intellisense does not show errors like:
Configuration and Logs
debug output from C/C++ extension: (in comment, because I reached 65536 character limit)(appears in project: https://github.com/vis4rd/monoshot/tree/renderer-refactor, but imo shoult be reproducible in any c++ code)
settings.json:Issue is reproducible even when no
c_cpp_properties.jsonexists, however I created it just to check if it changes anything (it does not) and for the sake of this issue.Used compiler in CMake is different than default Visual Studio one:
But for some reason these includes are indexed (snippet from above LSP log):
..I think they are causing this issue of "clang-diagnostic-error" - they have precedence over correct include paths from selected compiler.
Other Extensions
ms-dotnettools.vscode-dotnet-runtime ms-vscode.cpptools ms-vscode.cmake-tools
...and many others that I don't think they could influence this behavior
Additional context
No response