Objective-C provides no way to declare such a thing, so for this to
occur something else must have gone wrong. Unfortunately all we have
is a SourceKit crash log, so I couldn't write a test case. Hopefully
some day the assert will fire and we can handle this properly.
rdar://problem/41305904
...so that we don't have to depend on the ObjectiveC module having API
notes for a class it doesn't actually define.
Support for rdar://problem/40278479.
This is overkill when we could just be better about updating the
lookup table version, but it's hard to remember to do that when
changing something in ImportName.cpp or whatever.
This allows us to filter them out in cases that would otherwise be
ambiguous. The particular prompting situation looks a lot like the
test case: a protocol, plus a forward-declared class with the same
name. (Normally we ignore forward-declared classes, but SourceKit's
module interface generation feature makes dummy ClassDecls for them
instead.)
https://bugs.swift.org/browse/SR-4851
In particular, there are frameworks with more than 65536 entries for
'init' as a base name.
I can't think of a test case for this besides actually adding such a
massive framework, but the assertions that were added here should
catch the issue in Debug builds if it ever comes up again. I'm going
to go harden everything else that uses this API next.
rdar://problem/40828315
While the compiler can bridge C block types to Swift function types,
the Swift runtime cannot. Don't bridge block types to Swift function
types in Objective-C generic arguments, so
NSArray<some-block-type>
will get imported as
[@convention(block) (...) -> Whatever]
rather than
[(...) -> Whatever]
Fixes rdar://problem/40879067 in a fairly narrow way; the Clang
importer's approach to adjusting types based on context needs a
cleanup, but this is the safe, localized fix suitable for 4.2.
Introduce some metaprogramming of accessors and generally prepare
for storing less-structured accessor lists.
NFC except for a change to the serialization format.
When importing @compatibility_alias declarations check if underlying declaration
is generic and if so, forward generic environment and generic parameters (if any)
to newly created typealias declaration, otherwise there is going to be a mismatch
between type associated with typealias and its declaration which leads to crashes.
Resolves: rdar://problem/39849926
LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
...instead of relying on the one in the overlay in pre-4.2 versions of
Swift. This caused crashes in deserialization, which (deliberately)
doesn't respect availability.
There are three changes here:
- Remove UIEdgeInsets.zero and UIOffset.zero from the UIKit overlay.
- Always use the 4.2 name for UIEdgeInsetsZero and UIOffsetZero from
the underlying UIKit framework. (This is the nested name.)
- Ignore the unavailability messages for those two constants in
pre-4.2 Swift, since we're now relying on them being present.
The latter two, the compiler changes, can go away once UIKit's API
notes no longer specify different pre-4.2 behavior, but meanwhile we
need to keep compatibility with the SDKs released in Xcode 10b1.
https://bugs.swift.org/browse/SR-7879
These new types are not yet imported for Swift but they need to be
included in the switch cases to avoid -Wswitch warnings that get promoted
to errors when building with -Werror.
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.
Upstream has renamed the DEBUG() macro to LLVM_DEBUG. This updates swift
accordingly:
$ find . -name \*.cpp -print -exec sed -i "" -E "s/ DEBUG\(/ LLVM_DEBUG(/g" {} \;
