clang-tidy Code Analysis error unless useBuildPath=true

[richcarni]

I am using cpp and CMake tools, trying to keep everything as default as possible, but have run into an issue with my project when running Code Analysis. I get an error related to xmmintrin.h:

I've test that Code Analysis works OK with a basic CMake project

I then tested running clang-tidy directly from the command line with minimal compilation arguments (includes) and that also worked OK

Finally came to the workaround of setting useBuildPath=true:

"C_Cpp.codeAnalysis.clangTidy.useBuildPath": true,
"C_Cpp.default.compileCommands": "build/compile_commands.json",

So, not sure if this is a bug or expected behaviour? (Or me doing something stupid)

Not sure what arguments or how to check what arguments clang-tidy is being called with. I suspect that would shed some light on the issue

Happy to test further/provide more info as required

[sean-mcmanus]

It's a bug due to our extension not filtering out __SSE* system defines that break compilation with clang. Our current design when useBuildPath is false is prone to bugs like this, so setting useBuildPath to true is the recommended workaround for when a bug like this is hit.

Our next pre-release version should have a fix (unless there's some unexpected issue with it). We're planning to release it any day now.

[sean-mcmanus]

Well, the errors in your screenshot are fixed relating to the __builtin_* types, but there might be more issues. Are you getting other errors after that? If so, do you know what the root C++ system header that your code is referencing that is pulling in the xmmintrin.h? And is your repro on Windows with mingw or Linux?

[sean-mcmanus]

Actually, my testing was incorrect and it's not fixed. I need to know how the info previously mentioned in order tell if this is fixable or not, i.e. we can only fix it with the current design if there's some way to prevent clang-tidy from including/parsing the unsupported gcc intrinsics in the headers, such as via some preprocessor condition that is checked.

[richcarni]

The only error I get is related to xmmintrin.h, no errors after that

I don't know which library is pulling it in. I'm working on a numerical problem using Ceres Solver and Adept. I know Ceres has a bunch of dependencies including Eigen, ATLAS and others. Sounds like you need to where it is being included to investigate further - it doesn't seem straightforward, but I'll look into it

I am running on Linux, gcc 11.2.0

[richcarni]

It's Eigen

Eigen/Core -> src/Core/util/ConfigureVectorization.h -> xmmintrin.h

Let me know what further info I can provide

[sean-mcmanus]

Okay, thanks, that's what I was looking for.

[brosenberg42]

I am having the same problem except that when I add:

"C_Cpp.codeAnalysis.clangTidy.useBuildPath": true,
"C_Cpp.default.compileCommands": "build/compile_commands.json",

I get "'stddef.h' file not found". I tried setting export CPATH=/usr/lib/gcc/x86_64-linux-gnu/9/include, but that resulted in getting the __builtin errors again. I am using gcc 9.4.0 on Ubuntu 20.04.

[sean-mcmanus]

@brosenberg42 You need to set C_Cpp.codeAnalysis.clangTidy.path to the clang-tidy installed on your machine. See https://github.com/microsoft/vscode-cpptools/issues/9574

[sean-mcmanus]

@richcarni I've verified that the fix had made a few weeks ago fixes the issue with the Eigen library and gcc. It should be in our next release.

[richcarni]

Thanks @sean-mcmanus - will be sure to test in next release and report back

[sean-mcmanus]

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

[richcarni]

Unfortunately not having any better luck with v1.13.2. Still getting error citing xmmintrin.h

[richcarni]

If it's any help, I think I may have narrowed the issue down a little further (I figured out how to do logging for the extension)...

I created a basic hello world and added #include <eigen3/Eigen/Core>

The clang-tidy compilation options then include the following:

...
-I/usr/include/eigen3
-isystem/usr/include/c++/11
-isystem/usr/include/x86_64-linux-gnu/c++/11
-isystem/usr/include/c++/11/backward
-isystem/usr/lib/gcc/x86_64-linux-gnu/11/include
-isystem/usr/local/include
-isystem/usr/include/x86_64-linux-gnu
-isystem/usr/include

If I manually run (the system) clang-tidy with all the same arguments as the extension I get the same error. But if I just remove the -isystem/usr/lib/gcc/x86_64-linux-gnu/11/include argument, the error disappears and I get a sensible output

[sean-mcmanus]

Ah, sorry about that -- looks like my verification process had a flaw.

I figured out a fix for our next release. You can workaround it via using

    "C_Cpp.codeAnalysis.clangTidy.args": [
        "--extra-arg=-mno-sse2"
    ]

[sean-mcmanus]

Actually, it looks like in some cases -msse is required, so 1.13.3 won't have the automatic fix, but the previously suggested workaround should still work (unless your code base requires -msse for some reason).

[sean-mcmanus]

Fixed with 1.13.4 (pre-release): https://github.com/microsoft/vscode-cpptools/releases/tag/v1.13.4

[richcarni]

Can confirm this is now working for me! (1.13.4)

Thanks @sean-mcmanus for the updates