There are three modes of concern here:
1) User provides -vfsoverlay but not -Xcc -ivfsoverlay
Recommended behavior.
2) User provides -Xcc -ivfsoverlay but not -vfsoverlay
Legacy behavior. Clang will handle setup for the VFS.
3) User provides both -vfsoverlay and -Xcc -ivfsoverlay
Unsupported. We will ignore the clang VFS overlays and substitute our
own. We will also pop a warning about this.
Adds the -vfsoverlay frontend option that enables the user to pass
VFS overlay YAML files to Swift. These files define a (potentially
many-layered) virtual mapping on which we predicate a VFS.
Switch all input-based memory buffer reads in the Frontend to the new
FileSystem-based approach.
ClassDecl::getSuperclass() produces a complete interface type describing the
superclass of a class, including any generic arguments (for a generic type).
Most callers only need the referenced ClassDecl, which is (now) cheaper
to compute: switch those callers over to ClassDecl::getSuperclassDecl().
Fixes an existing test for SR-5993.
The documentation for this method states that this can return null if
the module unit represents [the] imported headers.
We have a crash report on dereferencing the result of this function
farther down, and I suspect it's hitting exactly that
case. Unfortunately we only have a back trace and no test case.
Fixes: rdar://problem/41888568
https://github.com/apple/swift/pull/16951 introduced a layering violation between the
AST and ClangImporter libraries; break the layering violation by moving the function
isInOverlayModuleForImportedModule() to ClangModuleLoader.
If the Clang declrations are *types*, canonical declaration in Swift is
imported for newest version of Swift. In interface generation, if the
declaration is versioned and it's imported as a member in either or both
version of Swift, we have to take compatibility typealias into account.
* Fixed 'ClangModuleUnit::getTopLevelDecls' to take isCompatibilityAlias() into account
* Fixed bugs in ClangImporter where member-to-member versioned types aren't properly imported.
* Fixed 'SwiftDeclConverter::importFullName' to check equality of getEffectiveContext()
* Fixed 'importer::addEntryToLookupTable' to check equality of getEffectiveContext()
(moved 'ClangImporter::Implementation::forEachDistinctName' to 'NameImporter')
This should no longer be needed with `-fapinotes-modules`. We would add
all header search paths as APINotes search directories which should not
be required.
This reverts commit bb16ee049d,
reversing changes made to a8d831f5f5.
It's not sufficient to solve the problem, and the choices were to do
something more complicated, or just take a simple brute force
approach. We're going with the latter.
This can't arise from a clean build, but it can happen if you have
products lingering in a search path and then either rebuild one of
the modules in the cycle, or change the search paths.
The way this is implemented is for each module to track whether its
imports have all been resolved. If, when loading a module, one of its
dependencies hasn't resolved all of its imports yet, then we know
there's a cycle.
This doesn't produce the best diagnostics, but it's hard to get into
this state in the first place, so that's probably okay.
https://bugs.swift.org/browse/SR-7483
This enables additional tests for the ClangImporter. This found a
missing piece in the `-enable-objc-interop` work that was done
previously. Address that and enable the tests. There are now the
following failing tests on Linux:
* sdk - depends on Foundation (not hermetic, see SR-7572)
* mixed-nsuinteger - depends on Foundation (not hermetic, see SR-7572)
* import-mixed-with-header-twice - requires apple/swift PR#16022
* can_import_objc_idempotent - requires apple/swift PR#16022
* objc_protocol_renaming - requires apple/swift PR#16022
ModuleDecl::forAllVisibleModules() now has a includeLinkOnlyModules
parameter. This is intended to be used when computing the set of
libraries to autolink.
This logic reuses parts of the main clang::CompilerInstance because
it's not necessarily cheap or convenient to set up a new one, but that
leaves us open to problems where Clang doesn't expect these objects to
go away. Fix the one people were hitting most recently (thanks, ASan!).
rdar://problem/38454494
The dynamic SDK overlay needs to be built with -fPIC. Ensure that the
clang importer is marking the external globals appropriately. This was
caught by building the swiftGlibc SDK overlay component in a dynamic
configuration. Failure to do so will create RIP-relative references on
x86_64 which may overflow at runtime.
DavidU would probably say this function needs to be split up more too,
and he wouldn't be wrong, but that's a bigger change. (The original
change is getting cherry-picked.)
