mordante wrote: > > Oh shit. I just realized that this is most likely a latent bug no matter > > what. We build the module with Clang 18, and then essentially try to load > > it with Clang 17 (aka Clang Tidy 17). AFAIK that's not guaranteed to work, > > and probably just happens to work currently with Clang 17 building and > > Clang 18 loading the module (assuming we even test that right now?). I > > think we may have to always match the Clang and Clang Tidy versions we use. > > I should probably keep out of these discussions but here I am:
You're welcome participate in the discussion. This is a public forum. > Matching Clang with Clang-Tidy versions feels only natural. For instance > "Member visit" requires new syntax (deducing this) and fixes available in the > latest Clang 18 nightly, so it was surprising to find out the test failing > due to Clang-Tidy being used in the CI. I guess this case happens rarely but > this means working on library features dependant on newly implemented > language features might have to be postponed to the release after. +1 > This change doesn't actually help you in this regard. We still support Clang > 16 and 17, so the CI would have simply failed at a later stage, but for the > same reason. > > @mordante I'd much rather see this fixed properly than tape over it with this > patch. Then I can prohibit clang-16 and clang-17. 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. 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
