...instead of crashing. Also drop the class if its generic
requirements depend on a type that can't be loaded (instead of
crashing).
rdar://problem/50125674
This is enough to let the test case in rdar://problem/40899824 pass,
and any callers of this function already need to be able to handle a
nullptr result. There's a lot more work to do in this area, but it's
nice to get the simple things working again.
This will also preserve @escaping and @autoclosure, which were previously
dropped. This could lead to mismatches between expected and actual
canonical types for serialization cross-references.
https://bugs.swift.org/browse/SR-8045, likely others
This mirrors how a bridging header is processed when compiling source
files: before any of the imports. This is important for LLDB to
recreate the source environment as closely as possible to how the
compiler does it; in the test case being added involving a non-modular
header file, failure to do so resulted in a deserialization
cross-reference crash.
Note that Serialization still sorts imports, which normal resolution
of imports in source does not do. So we're still not consistent. But
this is less important than handling textual includes (bridging
headers) before modular imports.
rdar://problem/40471329
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
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.)
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
