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
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
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
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')
As of r332598, clang::VersionTuple only stores '.' as delimiters. On input any
'_' are converted to the '.' representation. So by the time it gets to swift, we
are guaranteed to have a '.' representation. So we can just drop any reference
to the flag and carry on.
rdar://36765072
In APINotes, when an unversioned name overrides
a previously declared name with a Swift version, if the
previously declared name is guarded under version 4
the obsoleted version should be 4.2, not 5. In all other
cases, the obsoleted version is the next major Swift
version.
Fixes rdar://problem/39950937
Rather than ASTContext-allocating ConcreteDeclRef’s storage when there is a
non-empty substitution map, put the SubstitutionMap directly in the
ConcreteDeclRef. Simplify the various interfaces along the way.
Replace two prominent uses of SubstitutionList, in ConcreteDeclRef and
Witness, with SubstitutionMap. Deal with the myriad places where we
now have substitution maps and need substitution lists (or vice versa)
caused by this change.
Overall, removes ~50 explicit uses of SubstitutionList (of ~400).
When the swift_bridged_typedef attribute is present on a typedef,
import the underlying type as bridged (e.g., String) rather than as
its unbridged type (e.g., NSString).
Fixes rdar://problem/39497900.
Unfortunately imported classes still have to go through this
code path because it's the only place where we can calculate
inheritsSuperclassInitializers().
...and fix places where it was being used inappropriately.
- Don't use 'open' on non-class members in the importer.
- Use the existing 'copyFormalAccessFrom' instead of an ad hoc version
for synthesized typealiases for protocol conformances. (This can
change 'internal' down to 'fileprivate', but only where the
enclosing type was already 'private' or 'fileprivate'.)
- Fix 'copyFormalAccessFrom' to not copy '@usableFromInline' onto
declarations that don't support it (namely, the above typealiases).
This should have no visible effect in practice.
Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
This doesn't have a specific effect now, because all of these places
are likely to only see NameAliasType, but it is refactoring with the
intent of eliminating NameAliasType entirely.
The importer would only synthesize its own memberwise init if the
declaration had a zero initializer, which supresses Sema's automatic
synthesis. Trouble is we cannot rely on Sema synthesizing the
memberwise init in case we deserialize declarations after type
checking.
Some other changes caught this with an assert, so fix the importer
to do the right thing here.
As Doug pointed out in the original review where this went in, this
isn't the normal way to do a type substitution. However, all the usual
methods depend on the conformance's generic signature being fully
filled in. Add a comment because, well, I don't have a better answer.
Still to do: test and fix up the use of multiple enum_extensibility
annotations, possibly with API notes. This is important because the
definition of NS/CF_ENUM /includes/ enum_extensibility(open) as of
Xcode 9.0; there should be a convenient out people can use to declare
exhaustive enums in C that's backwards-compatible.
