================
@@ -263,6 +263,10 @@ makeCommonInvocationForModuleBuild(CompilerInvocation CI) {
// units.
CI.getFrontendOpts().Inputs.clear();
CI.getFrontendOpts().OutputFile.clear();
+ CI.getFrontendOpts().GenReducedBMI = false;
+ CI.getFrontendOpts().ModuleOutputPath.clear();
+ CI.getHeaderSearchOpts().ModulesSkipHeaderSearchPaths = false;
+ CI.getHeaderSearchOpts().ModulesSkipDiagnosticOptions = false;
----------------
jansvoboda11 wrote:
The `setBuildingModule(false)` call only applies to the top-level TU. Clang
modules that are imported by that TU have that set to `true`. My thinking was
that when we're scanning a C++ TU with named modules enabled and another C++ TU
with named modules disabled, they could theoretically still share the scanning
PCMs for Clang modules. (Is this assumption correct?) We can only achieve that
sharing if we remove the flags implied by named C++ modules enablement from the
scan invocation (`GenReducedBMI`, `ModuleOutputPath`). Your change in
`DependencyScannerImpl.cpp` looks good, but it'd be good to have a test that
checks the scanner itself doesn't produce more than one PCM variant in this
scenario.
Can you clarify why you're now also resetting `ModulesSkipHeaderSearchPaths`
and `ModulesSkipDiagnosticOptions` for the build command lines here in
`ModuleDepCollector.cpp`? AFAIK these are only used within the scanner to
increase performance - they don't make it into the build invocations, nor
should the driver invocations that scanner takes as an input have them enabled.
https://github.com/llvm/llvm-project/pull/161486
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
