New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-4008] Same-type constraint crasher in extension #46593
Comments
@swift-ci create |
Thanks for filing this. It's got nothing to do with "protocol extensions", though, right? |
Ah right, just extensions, yeah. Wonder if it crashes with a protocol in fact. |
Nope, it doesn't. This compiles just fine: extension Sequence {
func f<S: Sequence>() where Iterator.Element == Array<S.Iterator.Element> {
}
} |
Ben and I talked a little about this and realized this is technically looking for a new feature, since now we have a member with constrained applicability instead of an entire extension. Unfortunately, we can't write this as a constrained extension today; it would look something like this:
The compiler still shouldn't crash, though. Running the test case under LLDB shows we're blowing out the stack:
|
We do allow where clauses to place constraints on outer generic parameters now, and @DougGregor and @huonw have been fixing up same type constraints to work in their full generality. |
With 3.1 this gets an error that the constraint is recursive (“same-type constraint 'Element' == 'Array<S.Iterator.Element>' is recursive”), so this is a regression in detecting handling the recursion. |
Works on master. |
Additional Detail from JIRA
md5: 482df2673f2c353e75467686aadc8313
Issue Description:
Inside a type extension, constraining a generic parameter to be equal to another type that uses a generic argument from the function as a generic argument to the constraint crashes the compiler:
This doesn't appear to happen with protocol extensions, this compiles OK:
The text was updated successfully, but these errors were encountered: