[SR-1779] Generic Objective-C classes cannot conform to protocols with associated types #44388
OS X 10.11.5, Xcode 8S128d
Additional Detail from JIRA
I've attached an Xcode 8b1 project that contains a reproduction case. You can trigger the compiler segfault by attempting to run the unit tests (building the framework target alone isn't sufficient).
This bug is a little complicated. Here is the setup:
1. We have a framework target written in Objective-C. We've defined a generic Objective-C class `C` that conforms to an Objective-C protocol `P`.
2. To make things easier for our users, we provide a separate Swift file that is intended to provide additional functionality by making `C` conform to Swift's `Sequence` protocol.
2b. That file is not part of the framework target. In order to stand in for our users' applications, the file belongs to the unit test target, which acts like an application. The unit test target has a bridging header that pulls in our framework's Objective-C sources, and it also builds the aforementioned Swift file to provide the enhanced functionality.
3. That Swift file contains two things: a non-generic Swift class `Z` that is supposed to act as the iterator, and an extension to `C` to conform it to `Sequence` (by using `Z` as its iterator).
4. `Z` initializer takes in an argument of type `P`. The extension on `C` attempts to construct a `Z` iterator by passing in `self` to the initializer (since `C : P`, this should work).
5. Instead, the compiler crashes. I've attached the output as well in the text file.
The text was updated successfully, but these errors were encountered:
Just verifying this again. With beta 4, I get this error:
On master, I get this:
I'm assuming this is an unsupported case where the associated type depends on Objective-C generic parameters, which is something we'd like to allow eventually, but not yet.
It does not appear to make any difference:
I ran into this same issue conforming a generic Objective-C type to a Swift protocol with no associated types (and no requirements either). Adding an `@objc` annotation to the protocol fixed it, but it seems that the problem is broader than what is mentioned here.