This was fixed by 897effe, which I had originally thought would be a
no-functionality-change commit because it just made things lazier.
Turns out requirement signature deserialization can result in
circularity with sufficiently cross-referential conformances.
This isn't exactly a reduced test case because it still depends on
subclassing NSObject, which probably means there are hidden
dependencies on conforming to standard library protocols. But it's
better than nothing.
https://bugs.swift.org/browse/SR-5191
Some cases of using isSuperset can cause crashes, this was caused by improper subclassing callouts; this pr resolves those failures (and provides unit tests for that case)
The cases where the bridge was traversed too much now only causes a single bridge out call (without needing to reallocate or thrash retain/release)
String.components(separatedBy: CharacterSet) should be considerably faster now not only for more apporpriate bridging calls but also no longer needing to bridge arrays back and forth.
Resolves the following issues:
rdar://problem/17281998
rdar://problem/26611771
rdar://problem/29738989
Previously looking up an extension would result in all extensions for
types with the same name (nested or not) being deserialized; this
could even bring in base types that had not been deserialized yet. Add
in a string to distinguish an extension's base type; in the top-level
case this is just a module name, but for nested types it's a full
mangled name.
This is a little heavier than I'd like it to be, since it means we
mangle names and then throw them away, and since it means there's a
whole bunch of extra string data in the module just for uniquely
identifying a declaration. But it's correct, and does less work than
before, and fixes a circularity issue with a nested type A.B.A that
apparently used to work.
https://bugs.swift.org/browse/SR-3915
This "fixes" two issues:
- The name of a non-public typealias would leak into the public
interface if the extension had any public members.
- A common pattern of defining a platform-specific typealias for an
imported class and then extending that type would lead to
circularity when trying to deserialize the typealias. We /shouldn't/
be loading the extension at that point, but fixing that would be
much harder.
The "right" answer is to (a) check that the typealias is public if the
extension has any public members, and (b) somehow ensure there is no
circularity issue (either by not importing the extension as a result
of importing the typealias, or by the extension being able to set its
sugared base type later).
rdar://problem/29694978
Two of them are user-facing, with the following sort of message:
If you're seeing a crash here, check that your SDK and
dependencies match the versions used to build 'SwiftLib'
Prompted by rdar://problem/28282310, which took a while to figure out.
The added test case is a simplified version of the issue. (Obviously
we'd prefer to not crash here, but that's hard---there's an inherited
conformance that's no longer valid, and there may be generic types
depending on that conformance.)
Extend NSNumber bridging to cover not only `Int`, `UInt`, `Double`, and `Bool`, but all of the standard types as well. Extend the `TypePreservingNSNumber` subclass to accommodate all of these types, so that we preserve type identity for `AnyHashable` and dynamic casting of Swift-bridged NSNumbers. If a pure Cocoa NSNumber is cast, just trust that the user knows what they're doing.
This XFAILs a couple of serialization tests that attempt to build the Foundation overlay, but which don't properly handle `gyb` files.
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
Apart from being general compile-time goodness, this helps break a
circularity issue involving serialization cross-references and the
Clang importer.
The test is being added to validation-tests because it relies on
several levels of non-laziness in the compiler, all of which we'd
like to fix. It's making sure we don't regress here, but it isn't
actually verifying this change in particular.
rdar://problem/22364953
Swift SVN r31455
Compiler output at least up to serialization should be deterministic at this point,
at least when not taking SIL into account. This /should/ mean that changing a
function body should not affect the final built swiftmodule, which means downstream
targets don't need to be rebuilt. Leaving the previous swiftmodule output in place
signals that.
A while back I put in a push to get all the non-determinism out of type checking,
importing, and serialization itself; it looks like we've finally made it. Let's keep
it that way!
rdar://problem/20539158 and others
Swift SVN r29923
