One point of clarification: Would CIR also be tested for changes to llvm? (Which generally triggers testing for clang and mlir, so I assume “yes”, but it’s unclear from the RFC wording.)
I’m weakly -1 on this. Not so much for any reasons specific to CIR, but because I think that enforcing testing of the component in pre-commit CI and enabling it by default in the build should go hand in hand.
If CIR is tested in pre-merge, and contributors to Clang/MLIR are expected to resolve build and test failures themselves, then that effectively means that they also need to build and test CIR locally, just like they do for all the other code that is likely to be affected by their changes.
At least the first time a contributor hits a CIR failure in CI, they’ll have to add -DCLANG_ENABLE_CIR=On to their local build. Over time, this basically means that we end up implementing RFC: Enable ClangIR Build By Default-, just with each Clang contributor enabling it individually, and without actually reaching a consensus on that RFC.