-
Notifications
You must be signed in to change notification settings - Fork 10.6k
Optimizer: fix handling of dependent existential archetypes in alloc_stack
and apply
simplification
#83898
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
Optimizer: fix handling of dependent existential archetypes in alloc_stack
and apply
simplification
#83898
Conversation
@swift-ci test |
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.
LGTM
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.
There's a bunch of hacky stuff here and it would be nice if we didn't repeat the same mistakes we made in the C++ frontend implementation by using generics APIs incorrectly.
guard substitutionMap.replacementTypes.contains(where: { $0.isExistentialArchetype }), | ||
substitutionMap.replacementTypes.allSatisfy({ $0.isExistentialArchetype || !$0.hasLocalArchetype }) | ||
// TODO: support non-root existential archetypes | ||
guard substitutionMap.replacementTypes.contains(where: { $0.isRootExistentialArchetype }), |
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.
Why is this a precondition?
return type.isRootExistentialArchetype || | ||
// case 2. the argument _is_ a metatype of the existential archetype | ||
(type.isMetatype && type.canonicalType.instanceTypeOfMetatype.isExistentialArchetype) || | ||
(type.isMetatype && type.canonicalType.instanceTypeOfMetatype.isRootExistentialArchetype) || |
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.
Can't you handle all the cases by transforming the type recursively?
/// ``` | ||
func optimizeExistential(_ context: SimplifyContext) -> Bool { | ||
guard type.isExistential || type.isExistentialArchetype, | ||
// TODO: support non-root existential archetypes |
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 would prefer we just fixed this with the right abstractions. You can get this from the conformance of Self to the protocol, stored in the init_existential instruction.
@slavapestov we can think of making this improvements in a follow-up PR. But this PR is intended to be cherry-picked to 6.2 and should be at lowest risk. That means: just adding additional bail-out conditions |
@swift-ci smoke test windows |
…_stack` and `apply` simplification When replacing an opened existential type with the concrete type, we didn't consider that the existential archetype can also be a "dependent" type of the root archetype. For now, just bail in this case. In future we can support dependent archetypes as well. Fixes a compiler crash. rdar://158594365
c1cce39
to
56521f0
Compare
@swift-ci smoke test |
When replacing an opened existential type with the concrete type, we didn't consider that the existential archetype can also be a "dependent" type of the root archetype.
For now, just bail in this case. In future we can support dependent archetypes as well.
Fixes a compiler crash.
rdar://158594365