Make NS_TYPED_ENUMS ObjectiveCBridgeable when they wrap an object #15270
Conversation
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
Build failed |
|
Oops, |
This allows them to be used in generic arguments for NSArray et al. We already do this for the ones that wrap bridged values (like NSString/String), but failed to do it for objects that /weren't/ bridged to Swift values (class instances and protocol compositions), or for Error-which-is-special. In addition to this being a sensible thing to do, /not/ doing this led to IRGen getting very confused (i.e. crashing) when we imported a Objective-C protocol that actually used an NS_TYPED_ENUM in this way. (We actually shouldn't be using Swift's IRGen logic to emit protocol descriptors for imported protocols at all, because it's possible we weren't able to import all the requirements. But that's a separate issue.) https://bugs.swift.org/browse/SR-6844
|
Passed everything except that Linux failed on one of the new tests. @swift-ci Please smoke test |
| @@ -24,6 +24,9 @@ extension _SwiftNewtypeWrapper where Self.RawValue : Hashable { | |||
|
|
|||
| #if _runtime(_ObjC) | |||
| extension _SwiftNewtypeWrapper where Self.RawValue : _ObjectiveCBridgeable { | |||
| // Note: This is the only default typealias for _ObjectiveCType, because | |||
| // constrained extensions aren't allowed to define types in different ways. | |||
| // Fortunately the others don't need it. | |||
| public typealias _ObjectiveCType = Self.RawValue._ObjectiveCType | |||
There was a problem hiding this comment.
I don't trust the compiler to get this right consistently, because a typealias with the same name as an associated type, but in a constrained extension, isn't something modeled well in the conformance checker. You're already adding a synthesized typealias in the importer, so why do you need this?
There was a problem hiding this comment.
This is the one case the importer is skipping; I didn't want to have to resolve the _ObjectiveCType of the RawValue, especially when compiling an overlay where we may not have actually determined it yet. How bad do you think this is? (Note that it's not necessarily the original type; a swift_wrapper of an int is bridged to NSNumber.)
There was a problem hiding this comment.
I was thinking the that the swift_bridge attribute had all of the information, but of course it doesn't for NSNumber or NSValue. Slightly concerned that we'll be unable to form this type witness if the Clang importer imports one of these types after the type checker is gone, but I supposed #15254 should make that no longer an issue.
There was a problem hiding this comment.
I think if that happens we're hosed anyway for all the default value requirements, so I'm not going to worry about it. :-)
There was a problem hiding this comment.
Associated type witnesses get used in Type::subst calls a lot, and we've had a number of compiler crashes due to missing associated type witnesses in the importer. Value witnesses are less often used---only really by the specializer or (in this case) the SILGen bridging code---and hasn't been as much of an issue. Anyway, I'm okay with this solution.
This allows them to be used in generic arguments for NSArray et al. We already do this for the ones that wrap bridged values (like NSString/String), but failed to do it for objects that weren't bridged to Swift values (class instances and protocol compositions), or for Error-which-is-special.
In addition to this being a sensible thing to do, not doing this led to IRGen getting very confused (i.e. crashing) when we imported a Objective-C protocol that actually used an NS_TYPED_ENUM in this way.
(We actually shouldn't be using Swift's IRGen logic to emit protocol descriptors for imported protocols at all, because it's possible we weren't able to import all the requirements. But that's a separate issue.)
SR-6844 / rdar://problem/36911791, possibly others