anutosh491 wrote: Thanks for the reviews. I agree with them.
For @rnk , yes it totally makes sense to build a correct command, rather than fixing a corrupt one. So I removed the post-construction argument filtering. The driver now records whether its in-process cc1 callback supports repeated invocation and threads that through the `Compilation`, similarly to the existing diagnostics lifetime policy. `Clang::ConstructJob` therefore omits `-disable-free` while constructing a reusable cc1 command. Ordinary short-lived or subprocess cc1 commands still receive `-disable-free`. For @aganea , I made the integrated-cc1 policy explicit in the tests: positive cases now use `-fintegrated-cc1`, while the subprocess case uses `-fno-integrated-cc1`, so the tests do not depend on the platform’s `CLANG_SPAWN_CC1` default. In `cc1_main.cpp`, time-trace and fatal-error-handler initialization now happens only after argument parsing succeeds, so an early failure cannot leave process-global state installed for the next invocation. I tested this with a clean Clang build, all 8 ToolSession unit tests, and the relevant driver tests including `in-process-multiple-cc1.c`, `cc1-spawnprocess.c`, `clang-translation.c`, and `cc-print-proc-stat.c`. https://github.com/llvm/llvm-project/pull/222531 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
