================
@@ -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:
> > 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.
>
> I believe that they are also set for all compiler invocations which generate
> a BMI (here):
>
> https://github.com/llvm/llvm-project/blob/36dc2a941f531d6b5662f2ad2c11e7264e5d9622/clang/lib/Frontend/CompilerInvocation.cpp#L5016-L5023
Ah, I wasn't aware of that, thanks! This change makes sense then.
> > 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.
>
> Do all the the scanning modules appear in the output of `clang-scan-deps
> -format=full-experimental`? If so, this part of the test should check this.
> https://github.com/naveen-seth/llvm-project/blob/147a39de68a981a51de7d9333f7b476139c43599/clang/test/ClangScanDeps/modules-context-hash-from-named-module.cpp#L39C1-L51C20
>
> I’m not yet familiar with the internals of the scanning tooling in regards to
> the scanning modules. If not by adding a regression test, how could I check
> this? Where would the logic that controls this behavior live?
No, they don't make it to the output verbatim. The scanner may create multiple
internal variants of a single module (due to different `-ivfsoverlay` flags for
example) and after the scan decide that they can be merged into one variant (if
the `-ivfsoverlay` files didn't affect the module contents and can be dropped).
Only the merged module variant makes it to the scanner output.
To check the scanner-internal modules, you'd have to check the contents of the
module cache directory used by the scanner and figure out if there are more
variants than you expect. I believe we already have some tests in the
`test/ClangScanDeps` directory that use `find` for this.
To sum up, this change looks fine, but let's add a test for the number of
scanner-internal PCM variants created.
https://github.com/llvm/llvm-project/pull/161486
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
