Some old circularity-breaking code caused an unexpected null type, which led to crashes in the decl checker when trying to check that an `appendInterpolation` method in a different file would satisfy the informal requirement for one in a StringInterpolationProtocol conformer. This code appears to now be unnecessary, so this commit removes it. Fixes rdar://problem/55864759.
- Deinitializers never get a custom Objective-C name.
- Classes and protocols are never bridged themselves; that only matters
for structs and enums.
This avoids another circularity issue like the one in a8bc132565,
where the Clang importer ends up importing a class and hands it to the
type checker, which then asks about conformances. The conformance
lookup table goes to add the extension from the Swift module, except
that the Swift module is what asked for the import in the first place.
It's possible there's a more general solution here, but this
particular change is good even in the non-crashy cases, and definitely
safe for Swift 4.0. Even if the test case is even more idiosyncratic
than the last one.
The test case change for SourceKit is probably due to the first
category not triggering the import of the other two
categories. Changes in import order have been known to affect source
compatibility, though not frequently. However, categories are not
intended to be ordered in the first place. There's still more we can
do in this space, and implicitly depending on these calls /outside/ of
the importer to control category import order was quite brittle
anyway.
SR-5330 / rdar://problem/32677610
This addresses a crash where the compiler asks if an imported class
inherits initializers from its superclass /during the SIL passes/. In
this particular arrangement of subclasses and initializers (see test
case), this leads to us importing members of an Objective-C class for
the first time well after we've destroyed the type checker, and then
checking to see if an initializer added in a Swift extension can
prevent initializer inheritance. That initializer hasn't been
type-checked (because it's in another file and isn't supposed to
affect anything), and so the compiler chokes. A spot fix would merely
check for 'resolver' here and skip over the initializer if it doesn't
have a type, but it's not clear what the right semantics are in that
case.
The real issue here is that we don't support importing new declarations
after the type checker has been torn down, and that keeps causing us
problems, but that's a much bigger thing to fix.
https://bugs.swift.org/browse/SR-3853
