throwing away the ggc-intrins path also removes path to standard headers

[nolange]

Describe the bug

When using clang-tidy in some non-standard paths, the tool requires the correct include paths. CodeChecker (by default) will remove all paths where intrinsincs headers are found, both clang and gcc provide them in a directory that contains other important headers like stddef.h.

The logic throws away all paths to compiler internal headers, clang-tidy only can work if it can locate the clang runtime headers by itself. (which is not a given if you don't use clang + clang-tidy from the very same installation)

CodeChecker version

---------------------------------------------------------------
Kind                 | Version                                 
---------------------------------------------------------------
Base package version | 6.22.2                                  
Package build date   | 2023-07-13T15:52                        
Git commit ID (hash) | a3d35cfd509b995187288cd8631446415a334257
Git tag information  | 6.22.2                                  
---------------------------------------------------------------

[INFO 2023-10-10 15:58] - CodeChecker web version:
------------------------------------------------------------------------------
Kind                                | Version                                 
------------------------------------------------------------------------------
Base package version                | 6.22.2                                  
Package build date                  | 2023-07-13T15:52                        
Git commit ID (hash)                | a3d35cfd509b995187288cd8631446415a334257
Git tag information                 | 6.22.2                                  
Server supported Thrift API version | 6.53                                    
Client Thrift API version           | 6.53                                    
------------------------------------------------------------------------------

To Reproduce

That would need a statically compiled clang-tidy

• Make a project with a file referencing
• Use said clang-tidy

This will fail:

/usr/include/c++/12/cstddef:50:10: error: 'stddef.h' file not found [clang-diagnostic-error]
   50 | #include <stddef.h>

Expected behaviour

CodeChecker should append the path to stddef.h and not filter it out. adding --keep-gcc-intrin works, but this should be probably the default for clang-tidy, or the logic should be smart enough to filter out only intrinsics paths from gcc.

Desktop (please complete the following information)

• OS: Debian Linux x86
• Browser:Chromium
• Version: Bookworm / 12

Additional context Add any other context about the problem.

[bruntib]

Hi, The problem is that we either keep or filter some include paths in the analyzer command with -I, -isystem, or some similar flag. This works with the granularity of directories. The flag --keep-gcc-intrin keeps such a directory even if it contains a header file of which the name ends with ...intrin.h. According to my previous experiences, Clang can't consume these. So, in case a directory contains both stddef.h and an ...intrin.h (which may happen in a custom built gcc's standard library), then I can't see, how this issue can be solved. I'd be happy to learn some generic solution.

[nolange]

Not sure if you understood my problem. Those paths are clang's internal headers, not the ones from gcc, see this listing: https://packages.debian.org/bookworm/amd64/libclang-common-15-dev/filelist

I get that this will cause big mess if you use gcc's headers, but here you yank out clang's headers.

How about looking at the whole path and not throwing it out if it contains lib/clang ?

[bruntib]

Sorry, now I understand the problem. So here is how CodeChecker is supposed to work. If the compile_commands.json contains a build action which is compiled by gcc, then it lists the implicit include paths of that specific gcc and add those to the clang invocation. Except for the ones, containing gcc internal headers. But CodeChecker is not supposed to touch the clang's standard library. That should be still used by clang (implicitly). So this filtering of include paths should happen only for gcc standard library header paths. If it's not the case, then that's definitely a bug, and we should fix it.

[nolange]

I use clang as "normal" compiler, so those are the paths that are removed. The problem only exists with a custom built clang-tidy - a full clangsa works, reason being the "tooling" part adding the builtin path itself: https://clang.llvm.org/docs/LibTooling.html#builtin-includes (It's worth a discussion if my clang-tidy can be considered broken because of this)

• Codechecker should probably behave differently depending on the tool - clangsa is certain to be a full compiler + development installation, clang-tidy and cppcheck (potentially) are not
• if the option is --keep-gcc-intrin it should take care to only affect filtering gcc include paths. the path always seems to be in the form of */lib/gcc/x86_64-linux-gnu/10/include (All files further include the line This file is part of GCC.)
• and a stupid question: '*intrin.h' headers are x86 specific, if you want to filter out gcc-internal include paths, aint that a rather weak association? Probably locating some file like varargs.h would be better to locate the compiler-internal include directory