kadircet wrote: hi folks, this change triggered some other failures in a distance, you can see detailed analysis in https://github.com/llvm/llvm-project/pull/143695#issuecomment-2970691063.
but tl;dr; LLVM shares some state throughout a process. This isn't something new with this change, unittests were prone/fragile to this already. But this change somewhat exacerbated this situation. As test ordering was only affecting unittests within the same directory, now they're global across all clang unit tests. you can see a repro that I managed to extract at this particular commit (db2315afa8db1153e3b85d452cd14d5a1b957350). hopefully none of these tests should rely on certain aspects of the host environment and be reproducible (but even if not, i think the point is clear): ``` ninja AllClangUnitTests && ./tools/clang/unittests/AllClangUnitTests --gtest_filter=addTargetAndModeForProgramName.*:CodeGenTest.* --gtest_random_seed=1 --gtest_shuffle ``` I see that you already addressed some of this dependencies in the commit, but I am not sure if that actually scales. Would it make sense to have a custom main for `AllClangUnitTests` and register all targets, just like clang driver does? https://github.com/llvm/llvm-project/pull/134196 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
