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.)
Previously we set up the diagnostic options too early for these flags
to be honored, in order to diagnose problems in parsing the arguments
being passed to Clang. The solution is to decide that that diagnostic
engine is a temporary one and to create a proper one later. (And if
this sounds like a lousy solution, I don't disagree, but it's what
Clang does too.)
rdar://problem/39197895 and possibly something older but I can't find it
The MSVC environment does not have a `-isysroot` or `-sysroot`
equivalent. Instead, manually expand the sysroot to the path as a
prefix to `/usr/include` and treat the path as a system include
directory. This fixes a number of tests which use `-sdk` on Windows.
This reverts commit fa2a5779b1.
The Clang change associated with this is only on swift-5.0-branch as a
temporary solution. Bruno is working on a better fix for trunk, so the
Swift master-next branch should not include this.
rdar://problem/37828424
This sets the NeededByPCHOrCompilationUsesPCH language option when
emitting a brigding PCH.
rdar://problem/35056912
rdar://problem/30384801
Initial patch by Adrian Prantl
(cherry picked from commit 5d5f542fe4)
This sets the NeededByPCHOrCompilationUsesPCH language option when
emitting a brigding PCH.
rdar://problem/35056912
rdar://problem/30384801
Initial patch by Adrian Prantl
(cherry picked from commit 5d5f542fe4)
Previously the recommended pattern for having a "private" interface
for a public framework that was easy to strip out was to define an
explicit submodule named 'Private'. However, that makes it all too
easy to have dependencies from the public parts of the module on the
private parts, and other such problems. We're now recommending that
the private module map instead define a parallel module named with
"_Private" as a suffix. Clang already implemented this, but Swift
didn't get the same treatment.
This fix tries to avoid hardcoding too much; it notes that this kind
of remapping is limited to the name 'Private' as the second component
of a module hierarchy, but doesn't actually encode the mapping with the
"_Private" suffix.
rdar://problem/37553763
Like 0d347ac1, but for bridging headers. We can have multiple bridging
headers if someone is sneaking them into a library target, even though
we've tried to lock down on that. Up until now we've been pretending
they're all included at offset 0 in the dummy main source file, but
that causes problems in rare occasions involving precompiled headers.
(I'm being vague about what those circumstances are because I haven't
actually nailed them down yet, nor have I reduced the reproducing
project to something that can be checked in as a regression test. But
it's something like "we encountered this header through a particular
include path, but we thought that include path led to a different
header".)
Instead, reuse the fix we had for module imports: a monotonically
increasing include location in a fake (but allocated) buffer. This
will still put the bridging header first under normal circumstances,
but will also handle a mix of module imports and extra bridging
headers being loaded.
rdar://problem/34349832
