feat(ci): add Clang-tidy to Sheldon

Description

Right now, Clang-tidy is hardcoded in Sight CI via sight!717 (merged). Clang-tidy wasn't added as a Clang-tidy hook in the first place because it requires the presence of the compilation database (a compile_commands.json file generated by CMake). However, Clang-tidy would still be a nice addition to Sheldon: It'll allow to run the same checks as the CI, which will make fixing them easier, and some Clang-tidy checks have an autofix option, which could be used via Sheldon's -f option. Clang-tidy is slow though, so it won't be active by default.

Proposal

Optional section to give some functional or technical hints

Functional specifications

Workflow, UX/UI design, screenshots, etc...

• Two new hooks will be added:
  • clang-tidy runs all the checks which would run on the CI
  • clang-tidy-fix only runs the checks that have an autofix option
• Sheldon gains a new commandline option, --hooks, which allows to override the default set of activated hooks, instead of having to modify the configuration file
• The clang-tidy hooks behavior in regards to the compilation database presence may be configured. When the compilation database is generated, it is done in a temporary folder
  • always: The hook always generate a new compilation database
  • when absent: The hook generates a compilation database when none is present
  • never (default): The hook never generates a compilation database, if none is present, the hook aborts
• If clang-tidy-hook.build-path is set, it is the directory where the compilation database is searched for. By default, it is in the repository root directory. If it is set, the compilation database generation will occur in that directory instead of a temporary directory.

Technical specifications

Details of the implementation

The two new hooks will both live in a new file clang-tidy.py. They share that file as they will have a lot in common. The only thing that changes between them are the enabled checks.

These hooks will do the following:

• It checks for the existence and name of the run-clang-tidy script. run-clang-tidy and then run-clang-tidy-13 are checked. run-clang-tidy is a wrapper for clang-tidy that allows to process files in batch.
• It checks if compile_commands.json file is present in the directory specified by clang-tidy-hook.build-path, or in the repository root directory if no set. If it isn't set it might, or might not, generate it according to the behavior dictated by clang-tidy-hook.generate-compilation-db. If the compilation database must be generated (the behavior is always, or the behavior is when_absent and the compilation database is absent), it is done in the directory specified in clang-tidy-hook.build-path, and CMake is called with cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON, and -gmodules option is seded out, as it causes problem when using Clang-tidy. If it isn't set, it is done in a temporary directory, and the resulting compile_commands.json is copied to the repository root directory, with CMake called with cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++. If the compilation database is absent and the behavior is never, the hook immediately aborts.
• It actually runs run-clang-tidy -jN [-p clang-tidy-hook.build-path] [-fix] [-checks=...], where:
  • run-clang-tidy is the name found in the first phase (might be either run-clang-tidy or run-clang-tidy-13)
  • N in -jN is the number of cores on the computer, found using os.cpu_count()
  • [-p clang-tidy-hook.build-path] option is present if clang-tidy-hook.build-path is present
  • [-fix] is present if Sheldon is in fix mode
  • [-checks=...] is present when using clang-tidy-fix hook, and the list of check is the checks which provide an autofix and which we find interesting. When using clang-tidy hook, this option is not set as the list of check in the .clang-tidy file is used instead.

The new Sheldon option --hooks will be used in priority to determine active hooks, as a comma-separated list of hooks. If it isn't set, the behavior is as before: the deprecated fw4spl-hooks.hooks is used first, else sight-hooks is used, else the default hooks are used.

Test plan

Describe how you will verify that the implementation fulfils the specifications

There should be at least one test per check we activate.