[libc] Fix accidental inclusion of system libc headers.

[PaulkaToast]

Summary

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.

[sivachandra]

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?

[PaulkaToast]

In D80178#2043168, @sivachandra wrote:

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?

Ah -ffreestanding works as well and its much cleaner. Thanks for the recommendation!

[sivachandra]

libc/cmake/modules/LLVMLibCObjectRules.cmake

220

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?

[PaulkaToast]

libc/cmake/modules/LLVMLibCObjectRules.cmake

220

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.

[sivachandra]

libc/cmake/modules/LLVMLibCObjectRules.cmake

220

Add this as a TODO and include the full reasoning you mentioned.

[sivachandra]

Please update and format the commit message appropriately.

libc/cmake/modules/LLVMLibCObjectRules.cmake

add_library(
     OBJECT
     ${ADD_ENTRYPOINT_OBJ_SRCS}
     ${ADD_ENTRYPOINT_OBJ_HDRS}
   )
   target_compile_options(
     ${objects_target_name}
     BEFORE
     PRIVATE
-      -fpie ${LLVM_CXX_STD_default}
+      -fpie ${LLVM_CXX_STD_default} -ffreestanding
   )
   target_include_directories(
     ${objects_target_name}
     PRIVATE
       ${LIBC_BUILD_DIR}/include
       ${LIBC_SOURCE_DIR}
       ${LIBC_BUILD_DIR}
   )
add_custom_command(
       OUTPUT ${lint_timestamp}
       # --quiet is used to surpress warning statistics from clang-tidy like:
       #     Suppressed X warnings (X in non-user code).
       # There seems to be a bug in clang-tidy where by even with --quiet some
       # messages from clang's own diagnostics engine leak through:
       #     X warnings generated.
       # Until this is fixed upstream, we use -fno-caret-diagnostics to surpress
       # these.
-      COMMAND $<TARGET_FILE:clang-tidy> "--extra-arg=-fno-caret-diagnostics" --quiet
+      COMMAND $<TARGET_FILE:clang-tidy> --system-headers
+              "--extra-arg=-fno-caret-diagnostics" --quiet
               # Path to directory containing compile_commands.json
               -p ${PROJECT_BINARY_DIR}
               ${ADD_ENTRYPOINT_OBJ_SRCS}
       # We have two options for running commands, add_custom_command and
       # add_custom_target. We don't want to run the linter unless source files
       # have changed. add_custom_target explicitly runs everytime therefore we
       # use add_custom_command. This function requires an output file and since
       # linting doesn't produce a file, we create a dummy file using a

libc/src/.clang-tidy

 Checks: '-*,llvmlibc-*'
 HeaderFilterRegex: '.*'
 WarningsAsErrors: 'llvmlibc-*'
 CheckOptions:
   - key:             llvmlibc-restrict-system-libc-headers.Includes
-    value:           '-*, linux/*, asm/unistd.h'
+    value:           '-*, linux/*, asm/*.h, asm-generic/*.h'