JonChesterfield added a comment. Editing the tests in place to check for new driver properties would mean we lose coverage for the old driver and get a lot of churn if we need to back out the change.
How about taking some of the more interesting driver tests, duplicating them to only run the new driver, changing the content so it actually matches the new driver and making sure they make sense. We could / should do that before toggling the default. Then when the old pathway is erased, we also erase the tests which only check the behaviour of the old path, and the transient test near-duplication is gone. Same effect as changing the tests in place, just more resistant to reversion churn and has the nice property of continuing to check we haven't accidentally broken the old toolchain between now and when it is removed. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D122831/new/ https://reviews.llvm.org/D122831 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
