[PATCH] D147876: [clang-tidy] Support specifying checks as a list in the config file

Tue Apr 11 08:59:00 PDT 2023

carlosgalvezp added a comment.

> When the `.clang-tidy` file is checked into the source control(git). It means that anyone who contributes to the project will need to ensure that they have a version of clang-tidy that will be able to read the file.
> This can cause problems as binaries of clang-tidy aren't always provided for specific versions on certain platforms.

Isn't that expected though? All projects have expectations on the required dependencies to build their code. For example LLVM requires a compiler with C++17 support and a modern CMake that needs to be downloaded from the CMake website on older Ubuntu versions. Granted, those are backwards-compatible constraints, but nevertheless require that the user sets them up. It doesn't come out of the box in a regular distribution. Same applies to other C++ libraries, Python pip packages, etc. That's why typically projects should set up a sandboxed environment with pinned versions of dependencies to ensure they can always be built and linted at any point in time.

Take also for example Clang compiler, I can see in the release notes that they have removed 2 user-facing compiler flags:
https://clang.llvm.org/docs/ReleaseNotes.html#removed-compiler-flags

This means this compiler can no longer be used to compile code that has a checked-in CMakeLists.txt (or similar) that uses those compiler flags. How much of a problem that is? Should those projects really prevent Clang from cleaning technical debt and be user-friendly for the general public?

I do acknowledge that the proposed deprecation is much bigger since it will affect essentially all projects. I'm thinking perhaps we can simply extend the notice period so everyone has time to update, together with printing some warning?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147876/new/

https://reviews.llvm.org/D147876