-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[GSB] Always ensure that we wire up typealiases in protocol extensions. #14974
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
Conversation
We were only wiring up typealiases in protocol extensions under some circumstances, which meant that we could miss some equivalences between a typealias in one protocol and an associated type in an inherited protocol, which could manifest as a crash in IR generation. Fixes SR-7097 / rdar://problem/38001269.
@swift-ci please smoke test |
@swift-ci please smoke test compiler performance |
@@ -3743,13 +3743,11 @@ ResolvedType GenericSignatureBuilder::maybeResolveEquivalenceClass( | |||
if (!nestedPA) | |||
return ResolvedType::forUnresolved(baseEquivClass); | |||
|
|||
if (resolutionKind != ArchetypeResolutionKind::AlreadyKnown) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused. As far as I can tell this change just means that updateNestedTypeForConformance
now gets called with ArchetypeResolutionKind::AlreadyKnown
in addition to the other two kinds, but, I can't see a way in which that call actually does anything.
It seems like that function does three "interesting" things, but none of them happen with this kind:
- processes delayed requirements, but this is conditional on the kind being
CompleteWellFormed
https://github.com/apple/swift/blob/adfead025138474a5b4a6f3c1dee585c5654cc42/lib/AST/GenericSignatureBuilder.cpp#L2813 - creates a new archetype, but this is explicitly not meant to happen for
AlreadyKnown
https://github.com/apple/swift/blob/adfead025138474a5b4a6f3c1dee585c5654cc42/lib/AST/GenericSignatureBuilder.cpp#L2847-L2868 - does "more processing" to an archetype, conditional on
shouldUpdatePA
, which is only changed totrue
when creating a new archetype, i.e. it doesn't happen forAlreadyKnown
https://github.com/apple/swift/blob/adfead025138474a5b4a6f3c1dee585c5654cc42/lib/AST/GenericSignatureBuilder.cpp#L2872
What am I missing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're both right and... somewhere I messed something up locally, because the test marked as fixed doesn't seem to be fixed. Very sorry :(
This is the wrong way to go; the real fix is in #15002. |
We were only wiring up typealiases in protocol extensions under some
circumstances, which meant that we could miss some equivalences between a
typealias in one protocol and an associated type in an inherited protocol,
which could manifest as a crash in IR generation.
Fixes SR-7097 / rdar://problem/38001269.