Rework the relationship between generic environments and opaque archetypes #40747
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…Type As a small step toward moving away from having a bespoke generic environment for each OpaqueTypeArchetypeType, create the types without the generic environment and only build it lazily.
We were always mangling based on the last generic parameter, which makes sense when there is only one opaque result type, but is incorrect when there are multiple opaque result types, e.g., due to named or structural opaque result types.
…hing. Introduce a new primitive operation on opaque type archetypes that canonicalizes a type within the environment of the opaque type archetype without building the environment itself. Use it when matching opaque archetype types in the solver.
…ion. Creation of the "bound" generic signature isn't possible with interface types or type variables, so open up the opaque interface signature instead and separately bind the outer type parameters as appropriate.
…types. Teach `GenericEnvironment` how to lazily create opaque type archetypes, performing the contextual substitutions as required but without building the "bound" generic signature until required. To get here, augment `GenericEnvironment` with knowledge of the purpose of the environment, whether it is for normal cases (any signature), an opened existential type, or an opaque type. For opaque types, store the opaque type declaration and substitution map, which we also use to uniquely find the generic environment. Among other things, this ensures that different opaque type archetypes within the same opaque type declaration are properly sharing a generic environment, which wasn't happening before.
|
@swift-ci please smoke test |
…nment. When forming the generic signature of a generic environment for opaque types, substitute for the outer generic parameters based on the provided substitution map. We weren't able to do this before because the substitution cannot be performed when there are interface types or type variables involved. However, the lazy construction of this generic signature and use of other queries on opaque type archetypes ensures that we don't form new generic signatures until we have concrete types to work with. This enables same-type constraints amongst different opaque result types and their associated types.
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Teach
GenericEnvironmenthow to lazily create opaque type archetypes,performing the contextual substitutions as required but without
building the "bound" generic signature until required. To get here,
augment
GenericEnvironmentwith knowledge of the purpose of theenvironment, whether it is for normal cases (any signature), an opened
existential type, or an opaque type. For opaque types, store the
opaque type declaration and substitution map, which we also use to
uniquely find the generic environment. Among other things, this
ensures that different opaque type archetypes within the same opaque
type declaration are properly sharing a generic environment, which
wasn't happening before.
Altogether, this allows us to reason about opaque type archetypes
without going through the bound generic signature, which
should allow us to use type variables and interface types in
the substitution map.