The Clang Importer currently has a ridiculous re-entrant submodule loading path that winds up doing this anyways. Take Darwin as a prime example.
import Darwin.C.tgmath
In theory, this should load Darwin.C.tgmath and its immediate clang-only dependencies. In practice, namelookup::getAllImports winds up asking for the overlay associated with Darwin.C.tgmath. In order to load the overlay, it walks to the top-level module (Darwin) and tries to load a module with that name. Becuase we're in the middle of loading Darwin while importing tgmath, and because the compiler does not distinguish the act of loading a module from the act of loading an overlay, the Clang Importer would re-enter itself. The net effect is that every submodule import of a clang module *always* loads the top-most module and makes it visible. So
import Darwin.C.tgmath
actually becomes
import Darwin.C.tgmath
import Darwin
As long as we're here, and because this doesn't seem to actually hurt anything, let's optimize for this behavior. If the top-level module is requested, we need not call finishLoadingClangModule twice, just return the wrapper module it gives back.
Eventually, we should tame this implicit behavior with respect to overlay module loading.
We need to traverse the module dependency graph and track which modules expose
which other modules' ABIs, while making sure that we don't hit a loop while
trawling through Clang (sub)modules.
Fixes rdar://64993153.
The difference with `ModuleFile` is that `ModuleFileSharedCore` provides immutable data and is independent of a particular ASTContext.
It is designed to be able to be shared across multiple `ModuleFile`s of different `ASTContext`s in a thread-safe manner.
This adds support to `ClangImporter` to import C++ member function operators as static methods into Swift, which is part of SR-12748.
The left-hand-side operand, which gets passed as the `this` pointer to the C++ function is represented as an additional first parameter in the Swift method. It gets mapped back in SILGen.
Two of the tests are disabled on Windows because we can't yet call member functions correctly on Windows (SR-13129).
Expand the FrontendOptions to allow the enabling
of the dependency tracker for non-system
dependencies, and switch the previous clients of
`createDependencyTracker` over to using this
option. This ensures that the dependency tracker
is now set only during `CompilerInstance::setup`.
There's no reason clients need to be able to access this data directly.
It obscures where module loading is actually happening, and makes it too
easy to accidentally register a module with the wrong identifier in the
context.
Hide the registration operations behind opaque accessors.
clang::Decl::isHidden() is misleadingly named (see the associated FIXME
comment) and doesn't do what we want when
`-fmodules-local-submodule-visibility` is turned on.
This change alone isn't unfortunately enough to make Swift work with
`-fmodules-local-submodule-visibility`. For one thing, Clang's
Objective-C component doesn't work correctly with
`-fmodules-local-submodule-visibility`:
https://bugs.llvm.org/show_bug.cgi?id=46248
However, in the meantime, we should still clean up our use of
clang::Decl::isHidden().
The only caller consuming the data that resulted from this bit has it
set to false. Additionally, the side effect of force-loading the
overlays is already handled unconditionally by the call to
namelookup::getAllImports.
The ClangImporter currently calls into
`ObjCSelector`'s `lookupDirect` in a couple of
places, stashing the selector in a DenseMap to try
and avoid re-entrancy problems.
However this will become a problem once
`ObjCSelector`'s `lookupDirect` is both
requestified and starts pulling in members from
the main module, so migrate the ClangImporter off
calling it.
Fortunately most of its uses only care about decls
with associated Clang nodes. For those cases, we
can use the existing member table, making sure to
populate it with any method we import.
In one case, the ClangImporter needs to check to
see if there's a deserialized Swift method with a
matching selector. Instead of calling through to
`lookupDirect`, let's just query the Swift module
loaders directly.
Module interface builder used to maintain a separate compiler instance for
building Swift modules. The configuration of this compiler instance is also
useful for dependencies scanner because it needs to emit front-end compiler invocation
for building Swift modules explicitly.
This patch refactor the configuration out to a delegate class, and the
delegate class is also used by the dependency scanner.
Out handling of clang submodules was handled differently between DocInfo and
InterfaceGen. For InterfaceGen submodules were mapped back to their top-level
clang modules (or their Swift overlay if it had one) before being passed
into printSubmoduleInterface, along with the dot separated name of the submodule.
For DocInfo, they were not, and only the rightmost component of their name was
passed. The call to retrieve the decls from a ModuleDecl doesn't work if the
ModuleDecl wraps a clang submodule, so we were missing these decls.
InterfaceGen for submodules also shouldn't have been mapping the module back to
the overlay of top-level clang module, as that meant we ended up printing
import decls from the Swift overlay in the submodule's interface.
Resolves rdar://problem/57338105
Requestification addressed the bulk of the issues with the re-entrant
Clang Importer. Flush a hack that depended on that old state of affairs.
rdar://60111478
Implement a new "fast" dependency scanning option,
`-scan-dependencies`, in the Swift frontend that determines all
of the source file and module dependencies for a given set of
Swift sources. It covers four forms of modules:
1) Swift (serialized) module files, by reading the module header
2) Swift interface files, by parsing the source code to find imports
3) Swift source modules, by parsing the source code to find imports
4) Clang modules, using Clang's fast dependency scanning tool
A single `-scan-dependencies` operation maps out the full
dependency graph for the given Swift source files, including all
of the Swift and Clang modules that may need to be built, such
that all of the work can be scheduled up front by the Swift
driver or any other build system that understands this
option. The dependency graph is emitted as JSON, which can be
consumed by these other tools.
