SonarLint not working in C++ CMake project in Visual Studio 2022 (Unexpanded response file)

Please provide

  • Operating system: Windows 11
  • Visual Studio version: 17.10.0 Preview 2.0
  • SonarLint plugin version: 7.7.0.86423
  • Programming language you’re coding in: C++
  • Is connected mode used: No

And a thorough description of the problem / question:
I’m working on a c++latest project with CMake 3.29 and Visual Studio 2022 Preview and SonarLint doesn’t analyse my source and header files. The output says

Refreshing PCH file for D:\source\TradeBuddy\src\TradeBuddyClient\Widgets\Dashboard\TradeBuddyNewsWidget.h. PCH file location: C:\Users\...\AppData\Local\Temp\SLVS\PCH\8f5dd19e-8827-4e22-b1bc-3a95b6d6c6ee\PCH.preamble
[SecretsAnalyzer] Analyzing D:\source\TradeBuddy\src\TradeBuddyClient\Widgets\Dashboard\TradeBuddyNewsWidget.h
[SecretsAnalyzer] Finished analyzing D:\source\TradeBuddy\src\TradeBuddyClient\Widgets\Dashboard\TradeBuddyNewsWidget.h, analysis time: 0s
[SecretsAnalyzer] Found 0 issue(s) for D:\source\TradeBuddy\src\TradeBuddyClient\Widgets\Dashboard\TradeBuddyNewsWidget.h
[CFamily] Using cached rule settings
[CLangAnalyzer] Analyzing D:\source\TradeBuddy\src\TradeBuddyClient\Widgets\Dashboard\TradeBuddyNewsWidget.h
[CFamily Analysis] Unsupported configuration: Unexpanded response file is not supported:@src\TradeBuddyClient\CMakeFiles\TradeBuddyClient.dir\Debug\Widgets\Dashboard\TradeBuddyNewsWidget.cpp.obj.modmap.
[CLangAnalyzer] Failed to analyze D:\source\TradeBuddy\src\TradeBuddyClient\Widgets\Dashboard\TradeBuddyNewsWidget.h: See above for more information.

It looks like the file is analysed twice, first SonarLint says there are 0 issues in my file (there are issues which should be detected by SonarLint), and the message is shown in Visual Studio’s status bar.
Then it crashes saying it can’t analyse unexpanded response file TradeBuddyNewsWidget.cpp.obj.modmap, but this file doesn’t exist because it is not generated thanks to the suggestions of this topic sonarlint-does-not-detect-issues-when-using-c-standard-20-with-cmake/107682.

Thank you for your time.

Hi @Jacquwes and welcome to the community!

Thanks for sharing your issue with us. Could you check the version of CMake being used by Visual Studio? (the path to the CMake binary being used is printed in the CMake output pane in Visual Studio).

There is a CMake issue affecting CMake 3.28.1 and fixed in CMake 3.28.2 that results in an extra .modmap response file being added to the compile commands when compiling in C++20 mode. See the investigation in this thread for more details.

Since Visual Studio 2022 currently seems to ship an impacted version, could you try installing CMake separately, and configuring Visual Studio to use that installation instead? (Tools → Options → CMake → General → Enable custom CMake executable).

Best regards,
Michael

Hello michael.jabbour, thank you for your answer.

I am already using a standalone version of CMake instead of the one bundled with Visual Studio, which is CMake version 3.29.0-rc2.
I am compiling C++ 23 maybe that would create new unexpected problems?

Thank you for your time

Hello @Jacquwes,

I have just tried an example C++23 project with CMake 3.29-rc4, and I couldn’t reproduce the problem.

To share some background information, response files (specified in arguments prefixed with @) are text files that store a list of compiler commands, see here. When a command contains a reference to a non-existent response file, then the command is broken (as it can’t be understood by the compiler). The CMake bug I referenced in my previous response results in broken commands in the exported compile_commands.json. In other words, even if we had support for response files in SonarLint, we still won’t be able to process this broken compile_commands.json.

To help us identify where this bad argument is coming from, I would suggest that we try the following:

  • Could you share the “CMake” output from the Visual Studio output pane with us?

  • Could you check if you get the @TradeBuddyNewsWidget.cpp.obj.modmap argument in the generated compile_commands.json when you generate your CMake project outside of VS? e.g.:

    cd project_dir
    cmake -S .  -B new_build_dir -G "Ninja"
    
  • You can also try to use the VS-bundled CMake binary with the same command (C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe), in a different build directory. Once you do this, could you share the generated compile_commands.json files using both CMake versions with us? Do you get the problematic
    @TradeBuddyNewsWidget.cpp.obj.modmap in both cases?

Let me know if you prefer to share any of the information mentioned above privately so that I can start a thread with you.

Best regards,
Michael

Could you try removing the added lines (and maybe cleaning the build directory)?

set(CMAKE_CXX_USE_RESPONSE_FILE_FOR_INCLUDES 0)
set(CMAKE_C_USE_RESPONSE_FILE_FOR_INCLUDES 0)

If the problem is caused by the bug I mentioned earlier, then those variables shouldn’t have an impact on the behavior: I would still expect to see a reference to a non-existent .modmap file in the exported compile_commands.json even when these variables are removed.

Hello,

Thank you for your answers.
Indeed, removing the two set(CMAKE_C...) lines did not solve the issue, and generating the project inside and outside visual studio, with visual studio’s cmake and my standalone version all produced the compile_commands.json file with @....cpp.obj.modmap.
I have uploaded my CMake generation output here because it is very long.

Regards

Hi @Jacquwes,

I guess this means that the CMake bug can still be triggered in newer versions. Is the referenced response file ....cpp.obj.modmap also missing when using your standalone CMake version?

It is worth noting that we don’t support analyzing C++23 yet (but coming soon), and we don’t support C++20 modules yet.

If you are not using C++20 modules in your project, you can try to use an older version of CMake than 3.28 (since it is the version where the bug was introduced).