[clang] [clang][DependencyScanning] Reset options generated for named module compilations. (PR #161486)

[Jan Svoboda via cfe-commits]

================
@@ -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