This patch extracts the construction of Module within ModuleMap into a separate function.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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 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.
Ah, in that case it makes sense as-is. I just assumed they lived in the same library.
clang-format: please reformat the code