I found that because --system-headers flag was not included when running clang-tidy, errors produced from compiler provided headers were being suppressed. After passing this flag I realized that by including headers like stdint.h we were indirectly including headers from the system libc. To prevent this we pass -ffreestanding.
We don't want to pass --system-headers for all checks just the llvmlibc-restrict-system-libc-headers therefore we do a separate invocation of clang-tidy for this check.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Doesn't this trigger a "defining builtin macro" warning/error?
Does adding -ffreestanding to the compile step of the raw object file fix the problem you are seeing and also avoid tampering with __STDC_HOSTED__ macro?
libc/cmake/modules/LLVMLibCObjectRules.cmake | ||
---|---|---|
220–221 | Do we still need this? |
libc/cmake/modules/LLVMLibCObjectRules.cmake | ||
---|---|---|
220–221 | Ah yes, this breaks with something like llvm-header-guard. The restrict-system-libc-header check needs the --system-headers to ensure that we aren't transitively including through the compiler headers. To solve this we can use two invocations of clang-tidy, one that just runs the restrict-system-libc-header check with the --system-headers and the other invocation would run everything else. |
libc/cmake/modules/LLVMLibCObjectRules.cmake | ||
---|---|---|
220–221 | Add this as a TODO and include the full reasoning you mentioned. |
Do we still need this?
Normally, it should not be our business to check system headers. For example, when we add the LLVM header guard check, system headers will break?