-- is not handled correctly in compile_commands.json

[emptyVoid]

Feature Request

I'd like a setting which would do either of the following:

• disable configuration warnings entirely;
• disable particular warning Unable to resolve configuration with compilerPath;
• prevented automatic switching of "Output" window to "C/C++ Configuration Warnings" panel.

Current behavior is really annoying, whenever I build my project a few configuration warnings make "CMake/Build" panel go away.

[Colengms]

Hi @emptyVoid . Configuration warnings likely refer to legitimate issues trying to configure IntelliSense. If they are not accurate, that would seem to be something we should address. Could you provide the outputs, and the configuration that leads to it?

[emptyVoid]

Hi @Colengms. I believe it's just the lack of support for clang-cl.

I'm getting a lot of these:
[2/16/2023, 10:51:54 AM] Unable to resolve configuration with compilerPath "c:/program files (x86)/llvm/bin/clang-cl.exe". Using "cl.exe" instead.

Some details in the discussion #8777.
Please tell if more info is needed.

[sean-mcmanus]

Yeah, we support configuring with clang-cl.exe, but it looks like they may be a compilerArg (or "fragments") and/or clang version that we may not be handling correctly which is causing our querying of clang-cl.exe to fail -- can you provide the args and version being used? Setting "compilerPath": "C:\\Program Files\\LLVM\\bin\\clang-cl.exe" works for me with clang 15 without any compiler args.

[Colengms]

Hi @emptyVoid . It looks like we're failing to query clang-cl.exe for some reason. As Sean mentioned, this could be due to some compiler arguments that you're using that we're not handling correctly.

Could you enable "C_Cpp.loggingLevel": "Debug" and provide the output of the C/C++ Output channel leading up to the warnings? That log should include the full command line(s) we are using to query the compiler. We should be able to use that to reproduce the issue and investigate further.

[emptyVoid]

C/C++: output.txt
C/C++ Configuration Warnings: warnings.txt

Compile command:
C:\\PROGRA~2\\LLVM\\bin\\clang-cl.exe /nologo -TP -DBOOST_ALL_NO_LIB -DBOOST_FILESYSTEM_DEPRECATED -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -DBOOST_MPL_LIMIT_LIST_SIZE=30 -DBOOST_REGEX_CXX03 -DBOOST_THREAD_USE_DLL -DBOOST_USE_WINDOWS_H -DNDEBUG -DNOGDI -DNOMINMAX -DNTDDI_VERSION=0x06000000 -DUNICODE -DWIN32 -DWIN32_CLANG -DWINAPP -DWINVER=0x0600 -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_WARNINGS -D_ENABLE_ATOMIC_ALIGNMENT_FIX -D_HAS_AUTO_PTR_ETC=1 -D_ITERATOR_DEBUG_LEVEL=0 -D_NDEBUG -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D_WIN32_WINNT=0x0600 -D_WINDOWS -D_WINSOCK_DEPRECATED_NO_WARNINGS -Ddummy_EXPORTS -I..\\ -I..\\resources -I..\\implementation -Iimpexp -imsvc C:\\Users\\emptyVoid\\.conan\\boost\\1.80.0\\stable\\package\\c3a370f5cfcb083a90753a3e6dd3e4674a7ec845\\include /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MD /Zi /O2 /Ob1 /DNDEBUG /std:c++17 /GS /W4 /GF /Zi -fms-compatibility -fms-compatibility-version=19.14 -fmacro-backtrace-limit=5 -Xclang -fcxx-exceptions -Xclang -fexceptions -Wconversion -Wsign-conversion -Wfloat-conversion -Wshorten-64-to-32 -Wno-ignored-attributes -Wno-pragma-pack \"-Wno-#pragma-messages\" -Wno-ignored-pragma-intrinsic -Wno-switch -Wno-missing-field-initializers -Wno-macro-redefined -Wno-microsoft-include -Wno-nonportable-include-path -Werror-microsoft-exception-spec /MD /Od /Ob0 -fstandalone-debug -fdebug-macro -Werror -Wno-invalid-token-paste -Wno-error=deprecated /FoCMakeFiles\\dummy.dir\\Unity\\unity_0_cxx.cxx.obj /FdTARGET_COMPILE_PDB -c -- D:\\Projects\\dummy\\build\\CMakeFiles\\dummy.dir\\Unity\\unity_0_cxx.cxx

clang version:

>"c:\Program Files (x86)\LLVM\bin\clang-cl.exe" --version
clang version 7.0.0 (tags/RELEASE_700/final)
Target: i686-pc-windows-msvc
Thread model: posix
InstalledDir: c:\Program Files (x86)\LLVM\bin

[sean-mcmanus]

@emptyVoid The -- at the end is causing the problem -- it should work if you remove that. Do you know why that -- is there? We can probably add code to deal with that.

UPDATE: We have a fix to filter out the "--" from our compiler query, but if there's another scenario where that is needed to be handled differently we may have to revisit it.

[emptyVoid]

@sean-mcmanus I believe CMake adds --:

https://github.com/Kitware/CMake/blob/c9b27dace7e4110b25d5889e9c6952d0f4a7ca58/Modules/Platform/Windows-MSVC.cmake#L337-L342

[sean-mcmanus]

@emptyVoid Cool, thanks for finding that info. Our fix should handle that correctly then.

[emptyVoid]

Great, thanks!

[sean-mcmanus]

Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.14.4

[emptyVoid]

@sean-mcmanus I'm still getting the warning after updating to 1.14.4. Wasn't the issue fixed in 1.15.0 instead? (at least it's in 1.15.0 milestone)

[sean-mcmanus]

@emptyVoid The fix should be in 1.14.4. We filter out the "--" when doing the compiler querying. It's possible there might be another argument causing an issue? Is the repro info the same as originally?

[sean-mcmanus]

@Colengms Any idea what could be going wrong still?

[Colengms]

Hi @emptyVoid . I'm no longer able to reproduce an issue with the command line you provided above. Is that still the command line you are reproducing the issue with? Would you be able to isolate the repro into something you can zip up and share with us? We could use that to investigate further and validate a fix.

[emptyVoid]

@sean-mcmanus @Colengms
Yeah, the repro is the same.

Here's a simplified repro: dummy.zip

C/C++: output.txt
C/C++ Configuration Warnings: warnings.txt
C/C++ Diagnostics: diagnostics.txt

Compile command:
C:\\PROGRA~2\\LLVM\\bin\\clang-cl.exe /nologo -TP -Ddummy_EXPORTS /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MD /O2 /Ob2 /DNDEBUG /FoCMakeFiles\\dummy.dir\\dummy.cpp.obj /FdTARGET_COMPILE_PDB -c -- D:\\Projects\\dummy\\dummy.cpp

And the definition of my CMake Kit: cmake-tools-kits.zip

[sean-mcmanus]

I'm seeing /clang: not being properly added to the clang args. I'm not sure why yet.

[sean-mcmanus]

It looks like something is causing us to not detect your compiler as clang-cl or possibly even clang. What version of LLVM/clang-cl.exe are you using? Does running ""C:\Program Files (x86)\LLVM\bin\clang-cl.exe" /clang:-E /clang:-dM nul" have #define __clang__ 1 in the output?

[emptyVoid]

As I've mentioned above it's clang 7.0.0:

>"C:\Program Files (x86)\LLVM\bin\clang-cl.exe" --version
clang version 7.0.0 (tags/RELEASE_700/final)
Target: i686-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files (x86)\LLVM\bin

And your command gives an error:

>"C:\Program Files (x86)\LLVM\bin\clang-cl.exe" /clang:-E /clang:-dM nul
clang-cl.exe: error: no such file or directory: '/clang:-E'
clang-cl.exe: error: no such file or directory: '/clang:-dM'

[sean-mcmanus]

@emptyVoid Unfortunately, "/clang" only works with clang 8 or newer, i.e. our extension is not able to configure clang-cl 7. We could create an issue to tracking that, but it seems unlikely that we would add support for that old compiler though (i.e. from 2018). Are you able to upgrade to clang 8 or newer?

[emptyVoid]

Sadly no, that's not an option atm, since our huge code base with many third-party libraries is being built with the same clang.

[sean-mcmanus]

I've added an issue to track this at #10624 .

[sean-mcmanus]

Unfortunately, the issue doesn't appear to be fixable, so we've closed it.

However, you should be able to fix the issue by setting your compilerPath in c_cpp_properties.json to a clang-cl 8 or newer compiler. Your code would still be built with clang 7 (and compile_commands.json would still reference that version of clang-cl), but setting that compilerPath will enable us to be query that compiler correctly....assuming there isn't some other issue.

[emptyVoid]

Setting "C_Cpp.default.compilerPath": "C:\\Program Files (x86)\\LLVM8\\bin\\clang-cl.exe" reduces the number of warnings to 2.
But they are still annoying and do change the active panel to "C/C++ Configuration Warnings".

Would you be willing to implement the original feature request: to provide a setting to silence these warnings?

[Colengms]

Hi @emptyVoid . Could you clarify what configuration warnings you are getting now? I'd prefer to address the causes of configuration warnings rather than provide a way to suppress them, in order to ensure issues get reported and fixed.

I set up a repro and got a configuration warning that I tracked down to the fact that clang-cl does not support C language standards (even in clang-cl version 15. cl.exe now does support them, and clang-cl is supposed to mirror cl.exe command line args, so this would appear to be a clang-cl bug). This is also due to the fact that we're always attempting to query the specified compiler for both C and C++ configurations. (#9266 is related). I have a fix internally to address this, which should get into our next version. However, I only repro'ed one configuration warning. If you're encountering an additional configuration warning, could you provide more information what it is and how to reproduce it?

[emptyVoid]

Hi @Colengms. The same "Unable to resolve configuration" warnings.

Here's all the output I get with C_Cpp.default.compilerPath in settings.json set to clang version 8 (C:\\Program Files (x86)\\LLVM8\\bin\\clang-cl.exe).
C/C++: output.txt
C/C++ Configuration Warnings: warnings.txt
C/C++ Diagnostics: diagnostics.txt

And all the output with compilerPath in c_cpp_properties.json set to clang version 8 (C:\\Program Files (x86)\\LLVM8\\bin\\clang-cl.exe).
C/C++: output.txt
C/C++ Configuration Warnings: warnings.txt
C/C++ Diagnostics: diagnostics.txt

[Colengms]

Hi @emptyVoid . It looks some of those warnings are arising due to use of a custom configuration provider (CMake Tools). It's providing a custom browse path as well as a custom configuration for dummy.cpp containing containing c:/program files (x86)/llvm/bin/clang-cl.exe. While explicitly specifying a compilerPath in c_cpp_properties.json will override the compiler used in compile_commands.json, it does not override the compiler specified by a custom configuration provider. My guidance above was based on the assumption you were using the compileCommands field in your c_cpp_properties.json. The override of the compilerPath value in c_cpp_properties.json should work if you remove use of configurationProvider in favor of compileCommands.