This is an archive of the discontinued LLVM Phabricator instance.

[clang][modules] Consider M affecting after mapping M.Private to M_Private
ClosedPublic

Authored by jansvoboda11 on Aug 23 2022, 2:28 PM.

Details

Summary

When Clang encounters @import M.Private during implicit build, it precompiles module M and looks through its submodules. If the Private submodule is not found, Clang assumes @import M_Private. In the dependency scanner, we don't capture the dependency on M, since it's not imported. It's an affecting module, though: compilation of the import statement will fail when implicit modules are disabled and M is not precompiled and explicitly provided. This patch fixes that.

Depends on D132430.

Diff Detail

Event Timeline

jansvoboda11 created this revision.Aug 23 2022, 2:28 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2022, 2:28 PM
jansvoboda11 requested review of this revision.Aug 23 2022, 2:28 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2022, 2:28 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
jansvoboda11 edited the summary of this revision. (Show Details)Aug 23 2022, 3:02 PM
jansvoboda11 edited the summary of this revision. (Show Details)
benlangmuir added inline comments.Aug 24 2022, 11:16 AM
clang/lib/Frontend/CompilerInstance.cpp
2016

Not sure if this is a good idea, but have you considered having the scanner provide the module with Foo.Private= syntax instead? It would be nice to keep this hack contained to implicit builds if we can.

jansvoboda11 added inline comments.Aug 24 2022, 11:48 AM
clang/lib/Frontend/CompilerInstance.cpp
2016

Interesting idea, that didn't occur to me. What implementation strategy are you thinking of?

If we want to avoid this hack, it seems like we'd need to pass ModuleIdPath ImportPath instead of StringRef ModuleName to findOrCompileModuleAndReadAST() and friends. That would allow us to look up the most specific -fmodule-file= argument. I'm not convinced changing multiple functions (and then changing them back when we don't need the hack) is better than extending the hack to explicit modules.

The upside is that we wouldn't need to report M as a dependency. WDYT?

jansvoboda11 added inline comments.Aug 24 2022, 11:52 AM
clang/lib/Frontend/CompilerInstance.cpp
2016

Another thing to consider: implicit build would need to propagate the information that module Foo_Private needs to be spelled on the command-line as Foo.Private to the scanner.

benlangmuir accepted this revision.EditedAug 24 2022, 12:49 PM

LGTM once the windows test failure is fixed.

clang/lib/Frontend/CompilerInstance.cpp
2016

Okay, it sounds like the current patch is less invasive than the alternative. Thanks for talking it through.

This revision is now accepted and ready to land.Aug 24 2022, 12:49 PM
This revision was landed with ongoing or failed builds.Aug 24 2022, 2:36 PM
This revision was automatically updated to reflect the committed changes.