philnik777 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.
Definitely. @H-G-Hristov feel free to comment on things you have an opinion/question about. Having an outside view is often quite helpful. > 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. > 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. 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
