Skip to content

Conversation

eeckstein
Copy link
Contributor

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

@eeckstein
Copy link
Contributor Author

@swift-ci test

@eeckstein eeckstein requested review from aidan-hall, atrick, meg-gupta and nate-chandler and removed request for hborla and xedin August 25, 2025 15:24
Copy link
Contributor

@nate-chandler nate-chandler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@slavapestov slavapestov left a 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 }),
Copy link
Contributor

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) ||
Copy link
Contributor

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
Copy link
Contributor

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.

@eeckstein
Copy link
Contributor Author

@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

@eeckstein
Copy link
Contributor Author

@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
@eeckstein eeckstein force-pushed the fix-simplify-alloc-stack-apply branch from c1cce39 to 56521f0 Compare August 26, 2025 16:01
@eeckstein
Copy link
Contributor Author

@swift-ci smoke test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants