Correct way to set up clang-tidy with CMake and Visual Studio/MSVC?

[dograt]

Hi all, I have tracked down a few threads online that seem to imply that something like this should work using Visual Studio with CMake.

find_program(
      CLANG_TIDY_COMMAND
      NAMES
         clang-tidy
      NO_CACHE
)
cmake
      set(MY_CXX_CLANG_TIDY "${CLANG_TIDY_COMMAND};--extra-arg-before=--driver-mode=cl;--extra-arg=--std=c++17;--format-style=file" CACHE INTERNAL "")

set_target_properties(${TARGET_NAME} 
    PROPERTIES 
        CXX_CLANG_TIDY "${MY_CXX_CLANG_TIDY}"

However, the above setup isn't working for me. I'm getting a bunch of clang-diagnostic errors, even though my code compiles and runs just fine when Clang-Tidy is disabled. I've also tried the command with no additional flags at all, and it gives me the same result.

Error	G13DA7946	use of undeclared identifier 'value' [clang-diagnostic-error]	
Error	G13DA7946	use of undeclared identifier 'value' [clang-diagnostic-error]	
Error	G13DA7946	use of undeclared identifier 'value' [clang-diagnostic-error]	
Error	G13DA7946	use of undeclared identifier 'value' [clang-diagnostic-error]	
Error	G13DA7946	use of undeclared identifier 'value' [clang-diagnostic-error]	

Any ideas on where I can start poking around to diagnose what is going on?

[llvmbot]

@llvm/issue-subscribers-clang-tidy

[AaronBallman]

That looks to be executing clang-tidy. [clang-diagnostic-error] is emitted by clang-tidy when reporting errors that come out of clang itself, rather than tidy. So it seems like something else is causing you problems (perhaps a difference in command line options between the clang-tidy execution and the regular compiler execution?).

[dograt]

@AaronBallman Thanks for this insight, how could I go about investigating something like that? In my experience on other platforms, clang-tidy has been essentially plug-and-play with CMake.

[AaronBallman]

I think the first thing I would check is whether executing clang-cl (instead of cl.exe that comes with MSVC) to see if Clang issues the same error. If that's the case, then it's possible that clang and cl disagree about the code. If that's the case, then we'd have to dig into the actual code to determine which behavior is correct.

[dograt]

Thanks Aaron, I'll look into it. I also noticed that I forgot to include the following CMake command that finds clang-tidy:

find_program(
      CLANG_TIDY_COMMAND
      NAMES
         clang-tidy
      NO_CACHE
)

Does that seem above board to you? It returns the following:

1> [CMake] -- Clang-tidy command found at C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-tidy.exe

[AaronBallman]

That looks correct to me, and that seems to be finding a reasonable clang-tidy installation location.

[dograt]

That's frustrating, I would just expect this to work out of the box:

if (MSVC)
    set_target_properties(
        ${TARGET_NAME} 
        PROPERTIES
            CXX_CLANG_TIDY "clang-tidy;--extra-arg-before=-std=c++17"
    )
endif()

Would it matter that I am using a CMakePresets.json? Is there some other way to configure clang-tidy to get it working with Visual Studio?

[AaronBallman]

There's not enough information to figure out what the issue is. We'd need to see the source code that's getting diagnosed by clang-tidy, but currently it looks like clang-tidy is integrated into Visual Studio fine. Have you tried my suggestion of testing with clang-cl directly? Have you verified you're passing the same flags to clang-tidy as you are to cl? (e.g., you can definitely run into issues if you pass -std=c++17 to clang-tidy but pass /std:c++latest to cl)

[dograt]

Fair enough! I've generated a compile_commands.json , and pulled the representative output for one of the files:

{
  "directory": "C:/Users/me/Documents/Projects/my-project/builds/debug-msvc-64",
  "command": "C:\\PROGRA~1\\MICROS~2\\2022\\COMMUN~1\\VC\\Tools\\MSVC\\1435~1.322\\bin\\Hostx64\\x64\\cl.exe  /nologo /TP -DDEBUG_MODE -DDEVELOP_MODE -DLINALG_USE_EIGEN -DQT_DLL -DQT_OPENGL_LIB -DWIN32_LEAN_AND_MEAN -DWIN64 -DWITH_SDL2 -D_CRT_SECURE_NO_WARNINGS -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_FORTRESS_TEST_DIR=\\\"C:/Users/me/Documents/Projects/my-project/path_to_my_test_project\\\" -D_SOLUTION_DIR=\\\"C:/Users/me/Documents/Projects/my-project/path_to_my_test_project/../../../apps/myapp\\\" -D_UNICODE -IC:\\Users\\me\\Documents\\Projects\\my-project\\foundations\\foundations\\include -IC:\\Users\\me\\AppData\\Local\\Programs\\Python\\Python311\\include -IC:\\Users\\me\\Documents\\Projects\\my-project\\extern\\eigen\\include -IC:\\Users\\me\\Documents\\Projects\\my-project\\extern\\json\\_deps\\include -external:IC:\\Users\\me\\Documents\\Projects\\my-project\\extern\\googletest\\_deps\\googletest\\include -external:IC:\\Users\\me\\Documents\\Projects\\my-project\\extern\\googletest\\_deps\\googletest -external:W0 /permissive- /Zc:preprocessor /EHsc /Zi /Ob0 /Od /RTC1 -MDd /MP /bigobj /utf-8 /Zc:__cplusplus /wd4577 /wd4467 /wd26812 /wd26495 -std:c++17 /Fofoundations\\foundations\\tests\\CMakeFiles\\foundations_tests.dir\\main.cpp.obj /FdTARGET_COMPILE_PDB /FS -c C:\\Users\\me\\Documents\\Projects\\my-project\\foundations\\foundations\\tests\\main.cpp",
  "file": "C:\\Users\\me\\Documents\\Projects\\my-project\\foundations\\foundations\\tests\\main.cpp"
}

I am not sure if there is a better way to see what gets passed into cl, but I'm hoping this is helpful. Is there a way to see what exactly is getting passed into clang-tidy as well?

I noticed that the flag -std:c++17 is getting passed in. This seems like a weird hybrid of the -std=c++17 and /std:c++17 syntax, and to be honest I'm not much of an expert on these differences. Could the formatting here be messing things up?