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.
This simplifies fixing the master-next build. Upstream LLVM already
has a copy of this function, so on master-next we only need to delete
the Swift copy, reducing the potential for merge conflicts.
Teach the driver to pass the SDK version it computes (from the SDK
settings JSON in a Darwin-based platform's SDK) down into the frontend.
The frontend then sets that SDK version in the LLVM module, which
eventually makes its way into the Mach-O file.
Last part of rdar://problem/60332732.
An upstream clang changed ASTSourceDescriptor to not have a const
Module pointer. const_cast here to make this agree.
(cherry picked from commit a49bceeedf)
When we found Objective-C methods via selector lookup, we would skip the
“should we even try to import this?” check. If the Swift-name-as-derived-
from-Objective-C is different from the actual Swift name, we might try to
(redundantly) import something from the generated Objective-C header,
which can lead to crashes. The specific method causing problems was defined
like this in Swift:
@objc public class func using(index: AnyObject) -> AnyObject? { return nil }
which produced an Objective-C method like this:
+ (id _Nullable)usingIndex:(id _Nonnull)index;
The Swift name derived from the Objective-C method is `usingIndex(_:)`, which
of course does not match `using(index:)`, meaning that we think these two
methods are different (they aren’t).
The safe fix is to check whether we should import a given Objective-C method
declaration along the found-via-Objective-C-selector path, like we do with
normal name lookup. A longer term fix is to emit swift_name attributes for
such methods.
Fixes the fiendish Clang importer crash in rdar://problem/60046206.
Recent clang side change merges ObjCCategoryDecl with the same name. All re-declarations
of a category points to the first category as the canonical one. This patch keeps these
non-canonical redeclarations as separate extensions in Swift.
rdar://problem/59744309
