mordante wrote: > > Then I can prohibit clang-16 and clang-17. > > Yeah, that's the solution. clang-tidy defines the same version macros as > clang does, so prohibiting it from clang-16 is the same as prohibiting it for > clang-tidy 16.
What makes it currently hard for modules is that in the current situation it would mean modules would have about 0% coverage. > > IMO The biggest issue is that the clang-tidy version is hard-coded in > > CMake. This is something I mentioned in the past too. If it was a CMake > > option it would be trivial to change the value without changing > > CMakeList.txt. > > We could also extract the clang version used and search for a clang-tidy that > fits this version. That would also avoid the matching problems for others. We > would probably have to get a path to the corresponding clang-tidy too. I > don't know whether that's trivially possible right now. I think matching the version would be trivial for the additional libraries. For the executable it might be harder, but there we can let the user specify an executable and if specified test that version. Then we can issue a diagnostic when the versions don't match. https://github.com/llvm/llvm-project/pull/76268 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
