Front-end: add a new module loader that loads explicitly built Swift modules #32170
Conversation
nkcsgexi
force-pushed
the
explicit-module-loader
branch
from
e663888 to
be687b1
Compare
|
@swift-ci please smoke test |
…modules To support -disable-implicit-swift-modules, the explicitly built modules are passed down as compiler arguments. We need this new module loader to handle these modules. This patch also stops ModuleInterfaceLoader from building module from interface when -disable-implicit-swift-modules is set.
nkcsgexi
force-pushed
the
explicit-module-loader
branch
from
be687b1 to
bd782be
Compare
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
| } | ||
|
|
||
| std::unique_ptr<llvm::MemoryBuffer> | ||
| ModuleFile::getModuleName(ASTContext &Ctx, StringRef modulePath, |
There was a problem hiding this comment.
Why do we need to load the module here? Can we instead provide more information on the command line, e.g., a specific mapping from module name to the module file the contains it?
There was a problem hiding this comment.
Yeah, we could do that to avoid loading modules eagerly. How about we accept a JSON file from the command line to include module name, module path, swiftdoc path and swiftsourceinfo path?
|
|
||
| // If implicit modules are disabled, we need to install an explicit module | ||
| // loader. | ||
| if (Invocation.getFrontendOptions().DisableImplicitModules) { |
There was a problem hiding this comment.
How about modeling DisableImplicitModules as a ModuleLoadingMode? It fits in with the scheme established there.
| } | ||
| // We found an explicit module matches the given name, give the buffer | ||
| // back to the caller side. | ||
| *ModuleBuffer = std::move(it->getValue().moduleBuffer); |
There was a problem hiding this comment.
We also need to deal with the .swiftdoc and .swiftsourceinfo as well, right?
| IgnoreSourceInfoFile); | ||
| Context->addModuleLoader(std::move(ESML)); | ||
| } | ||
| if (MLM != ModuleLoadingMode::OnlySerialized) { |
There was a problem hiding this comment.
When ExplicitSwiftModuleLoader is added, it seems like we should not add ModuleInterfaceLoader or SerializedModuleLoader at all. Then we don't need checks for DisableImplicitModules anywhere.
3 participants
To support -disable-implicit-swift-modules, the explicitly built modules
are passed down as compiler arguments. We need this new module loader to
handle these modules.
This patch also stops ModuleInterfaceLoader from building module from interface
when -disable-implicit-swift-modules is set.