This clang-cl driver change removes the PCH options when we are only generating preprocessed output. This is similar to the behavior of Y-.
• thakis erichkeane
- rG1696eef2ac42: Merging r340025:
rGeaca3883089a: Fix for bug 38508 - Don't do PCH processing when only generating preprocessor…
rL345311: Merging r340025:
rC340025: Fix for bug 38508 - Don't do PCH processing when only generating preprocessor…
rL340025: Fix for bug 38508 - Don't do PCH processing when only generating preprocessor…
The approach lgtm, thanks.
How does the gcc driver codepath handle this? Does it just not have to worry about this because it doesn't have something like warn_pp_macro_def_mismatch_with_pch?
|368 ↗||(On Diff #160365)|
Can we have an integration-test type test that creates a pch and uses it, and checks that there are no warnings? (Like in https://bugs.llvm.org/show_bug.cgi?id=38508#c1) Probably fairly easy to add to one of the test/PCH/pch-through* files.
Interestingly I'd say. So the gcc PCH model uses -include pch.h to use a PCH. In the driver, -include pch.h is handled by locating a matching pch file (say pch.h.gch) and if found adds -include_pch pch.h.gch instead of -include pch.h. This occurs even when only preprocessing (-E). When preprocessing the compiler then handles the -include_pch option by opening pch.h.gch, finding the original file that created it (pch.h) and doing what -include pch.h does. Seems like it would be better handled by the driver but maybe there is a reason for it.
When we only allowed PCH with a single /FI the model was the same as gcc and it worked similarly. Since the through header/MS model allows creation of a PCH from any tokens not just a single #include, we can't handle it this way anymore.