This is an archive of the discontinued LLVM Phabricator instance.

[clang][lex] NFC: Extract module creation into function
AbandonedPublic

Authored by jansvoboda11 on Jan 6 2022, 8:17 AM.

Details

Summary

This patch extracts the construction of Module within ModuleMap into a separate function.

Diff Detail

Event Timeline

jansvoboda11 requested review of this revision.Jan 6 2022, 8:17 AM
jansvoboda11 created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJan 6 2022, 8:17 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

I suppose the idea is that all Module creations should go through makeModule, right? In that case I think we should either

  • make the Module constructor private and ModuleMap a friend of Module
  • or at least add a doc comment to the Module constructor that says Modules should only be created using ModuleMap::makeModule.

Or are there other places that also create Modules but are not supposed to go through ModuleMap::makeModule?

I suppose the idea is that all Module creations should go through makeModule, right? In that case I think we should either

  • make the Module constructor private and ModuleMap a friend of Module
  • or at least add a doc comment to the Module constructor that says Modules should only be created using ModuleMap::makeModule.

Or are there other places that also create Modules but are not supposed to go through ModuleMap::makeModule?

The intent here is for all calls to the Module constructor in ModuleMap to go through makeModule(). This will make it possible to ensure a callback is always invoked when a Module is constructed in D113676.

Making the constructor private doesn't aid that goal, so I'd be inclined to do that in a separate patch. But would that be the right thing to do?
We don't instantiate Module outside of ModuleMap in the upstream repo, but I don't think there's anything fundamental that would prevent downstream projects doing that. Do we care about such use-cases though?

I just want to make sure that we don’t accidentally introduce a new instantiation of a Module that doesn’t go through makeModule in the future.

I just want to make sure that we don’t accidentally introduce a new instantiation of a Module that doesn’t go through makeModule in the future.

I understand that, but I'm not sure that's a desirable restriction in all situations. Moreover, Module resides in the clangBasic library while ModuleMap resides in clangLex. Befriending ModuleMap or otherwise tying Module to ModuleMap violates the library layering.

ahoppen accepted this revision.Jan 7 2022, 5:36 AM

Ah, in that case it makes sense as-is. I just assumed they lived in the same library.

This revision is now accepted and ready to land.Jan 7 2022, 5:36 AM
jansvoboda11 abandoned this revision.Mar 16 2022, 8:38 AM

Abandoning this. We don't need to collect usage info from -fimplicit-module-maps because we don't use that feature during explicit builds: D120465. Support for usage collection for modules was removed entirely in D121295.

Herald added a project: Restricted Project. · View Herald TranscriptMar 16 2022, 8:38 AM