[libc] update tidy rules to fix variable formatting

[michaelrj]

Summary

This commit changes the clang-tidy rules for LLVM-libc to follow the new
format. The next commit applies these rules to the codebase.

The rules are as follows:

CamelCase for classes
lower_case for variables
lower_case for functions
UPPER_CASE for constexpr variables

There are also some exceptions, but the most important one is that any
function or variable that starts with an underscore is exempt from the
formatting.

[michaelrj]

update lint rules to better reflect the codebase. Also add a .clang-tidy file to the build folder to prevent the generated code from being formatted (that tends to mess everything up)

[michaelrj]

add an exception for src/__support/CPP because it's supposed to match external code and thus might not match the internal format.

[michaelrj]

add exception for variables starting with underscores and fix exception for functions starting with underscores.

[sivachandra]

libc/CMakeLists.txt

63

Do we still require this?

libc/src/.clang-tidy

3

Can we add readability-* rules also to this list?

12

Can you give examples as to why this cannot be lower_case?

24

Do we still need this blanket ignore?

[michaelrj]

address comments

libc/CMakeLists.txt

63

yes. The variables in build/projects/libc/config/linux/syscall.h are of a specific format (that being the names of specific registers), and the formatter will raise errors if those aren't specifically ignored.

libc/src/.clang-tidy

3

not with the patch as it currently is, because in the generated signal.h file, the function sigaction is being renamed to __sigaction by the macro #define sigaction __sigaction, which for some reason ignores all of the exceptions I have put in place to handle it. If we rename the struct __sigaction to something that the linter doesn't think would be formatted to sigaction (e.g. __sigaction_struct) then it works fine, but I don't know if that's an acceptable solution.

24

No, removed.

[sivachandra]

libc/src/.clang-tidy

3

I think that can be fixed up as a follow up. You have added the readability-identifier-naming, is that something you forgot to take out?

[michaelrj]

libc/src/.clang-tidy

3

no, that's what enables that specific check.

libc/CMakeLists.txt

 option(LLVM_LIBC_ENABLE_LINTING "Enables linting of libc source files" OFF)
 if(LLVM_LIBC_ENABLE_LINTING AND (NOT LLVM_LIBC_FULL_BUILD))
   message(FATAL_ERROR "Cannot enable linting when full libc build is not enabled.")
 endif()
 if(LLVM_LIBC_ENABLE_LINTING)
   if("clang-tools-extra" IN_LIST LLVM_ENABLE_PROJECTS
              AND "clang" IN_LIST LLVM_ENABLE_PROJECTS)
     add_custom_target(lint-libc)
+    if(NOT EXISTS "${LIBC_BUILD_DIR}/.clang-tidy")
+      # add a no-op clang tidy file for the build directory so that the tidy 
+      # rules don't attempt to format the generated code.
+      file(WRITE ${LIBC_BUILD_DIR}/.clang-tidy "#InheritParentConfig: false
+      Checks: cppcoreguidelines-avoid-goto")
+    endif()
   else()
     message(FATAL_ERROR "
       'clang' and 'clang-tools-extra' are required in LLVM_ENABLE_PROJECTS to
       lint llvm-libc. The linting step performs important checks to help prevent
       the introduction of subtle bugs, but it may increase build times.
 
       To disable linting set LLVM_LIBC_ENABLE_LINTING to OFF
       (pass -DLLVM_LIBC_ENABLE_LINTING=OFF to cmake).")

libc/cmake/modules/LLVMLibCObjectRules.cmake

add_custom_command(
       #     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
+              "--export-fixes=${CMAKE_CURRENT_BINARY_DIR}/${target_name}.yaml"
               # Path to directory containing compile_commands.json
               -p ${PROJECT_BINARY_DIR}
               ${ADD_ENTRYPOINT_OBJ_SRCS}
       # See above: this might be a second invocation of clang-tidy depending on
       # the conditions above.
       ${restrict_system_headers_check_invocation}
       # 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

libc/src/.clang-tidy

-Checks: '-*,llvmlibc-*'
+Checks: '-*,llvmlibc-*,readability-identifier-naming'
 HeaderFilterRegex: '.*'
 WarningsAsErrors: 'llvmlibc-*'
 CheckOptions:
   - key:             llvmlibc-restrict-system-libc-headers.Includes
     value:           '-*, linux/*, asm/*.h, asm-generic/*.h'
+  - key:             readability-identifier-naming.ClassCase
+    value:           CamelCase
+  - key:             readability-identifier-naming.StructCase
+    value:           aNy_CasE
+  - key:             readability-identifier-naming.MemberCase
+    value:           lower_case
+  - key:             readability-identifier-naming.VariableCase
+    value:           lower_case
+  - key:             readability-identifier-naming.VariableIgnoredRegexp
+    value:           "^_[A-Za-z0-9_]+$"
+  - key:             readability-identifier-naming.FunctionCase
+    value:           lower_case
+  - key:             readability-identifier-naming.FunctionIgnoredRegexp
+    value:           "^_[A-Za-z0-9_]+$"
+  - key:             readability-identifier-naming.ConstexprVariableCase
+    value:           UPPER_CASE
+  - key:             readability-identifier-naming.GetConfigPerFile
+    value:           true