SILGen and SIL type lowering support for vanishing tuples #64887
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
AbstractionPattern. The old logic was wrong for vanishing tuples: a non-tuple substituted type might correspond to multiple lowered parameters if it's the result of substituting into a vanishing tuple that also contains empty pack expansions. Test to follow later in this PR.
Fixes a host of problems with stored type members with types dependent on a type parameter pack; I ran into it specifically with vanishing tuples. Test to follow.
Test to follow.
Fixes rdar://107459964 and rdar://107478603.
|
@swift-ci Please test |
|
@swift-ci Please test |
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.
The language says that
( type-tuple-body )is a tuple type only iftype-tuple-bodyis not a single non-expansion component; otherwise it is merely parentheses. We follow this same idea in substitution: substitution of type parameter packs can change the number of components in a tuple, and the result is no longer a tuple if there is a single non-expansion component. These "vanishing" tuples pose an annoyance for the lowering of types and expressions: lowering must often consider the unsubstituted type of declarations (the "abstraction pattern"), and it has historically been true that the substituted type will be a tuple if the unsubstituted type is. There is therefore quite a bit of code in lowering that assumes that e.g. it can check whether the substituted type is a tuple before it checks the unsubstituted type. This code must be fixed to be primarily driven by the unsubstituted type. (The original tuple structure is usually very significant! For example, if we take a formal parameter of type(Int, repeat each T), we will actually have two lowered parameters, one of which completely disappears from the substituted type ifTis substituted with an empty pack.)