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-12534] Segfault + type of expression is ambiguous without more context #54977
Comments
@swift-ci create |
It takes a lot to untwist this example, but ultimately it's failing to resolve the conformance of `S2<B, Z>` to `SS`. `B` is referenced recursively as a protocol requirement rather than as a generic parameter, which may be the consequence of several lookup-related changes we've made in 5.2. Either way, whatever `B` maps to, I would encourage you to define it explicitly in the conformance and give it a name that does not conflict with the protocol requirement. |
Comment by Matthew Johnson (JIRA) Thank you for tracking this down. I apologize for the complexity - it took quite a while to boil this down from proprietary code and I didn't have time to simplify further. Now that you understand what is going on, would you say that the Swift 5.1 behavior is correct? Or are you suggesting that when the crash is fixed behavior will be different going forward (such as a build error)? The `B` in the `SS` conformance is even getting inferred rather than being explicitly stated in Swift 5.1. Are there any general recommendations we can follow to avoid issues when providing a conformance that involves type parameter / associated type conflicts like this? Or should inference just work here like it did in 5.1? In this particular case neither `S2` or `SS` are intended to be aware of the existence of the other at all. So in some sense, the name `B` being used in both places is coincidental. The app itself is the only thing aware of both, so the usual caveat of not conforming a type from a different module to a protocol from a different module doesn't apply. |
Comment by Matthew Johnson (JIRA) @CodaFi I updated the relevant code in my production project so the protocol and the type parameter are no longer the same and I'm still seeing a segfault in the compiler. |
Ah, turns out all you needed was S2.C to be resolved here extension S2: SP {
public enum A { case a }
public func a(_ a: S2.A) { }
public var b: LS<B, Z> { _b }
public typealias C = LS<B, Z>
} |
Still, the compiler should not crash on this code. Associated type inference is not registering missing witnesses when it resolves S2: SP, it just substitutes in the ErrorTypes it gets while resolving the broken conformance. This seems like a regression in associated type inference. We should be able to infer C from the value witness public func c(_: @escaping (LS<B, Z>) -> Void) { } |
Breaking the inheritance relation between SS and SP also doesn't crash because associated type inference can see the value witnesses in SP and try them first instead of trying to resolve SS first, find no value witnesses to infer from, and pick up error types. |
Attachment: Download
Additional Detail from JIRA
md5: efe5a0167c1f9d308b4c1005db2b545e
Issue Description:
The attached sample project compiles fine in Swift 5.1 / Xcode 11.3 but has issues in Swift 5.2 / Xcode 11.4
The text was updated successfully, but these errors were encountered: