[5.9][ConstraintSystem] Anthology of changes to variadic generics #65586
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
xedin
added
🍒 release cherry pick
|
@swift-ci please test |
1 similar comment
|
@swift-ci please test |
…able pack expansion Examine pack expansion pattern to determine whether expression result could be discarded without a warning (applies to tuples with a single unlabeled pack expansion element as well). Resolves: rdar://108064941 (cherry picked from commit dc8c05a)
…on types (cherry picked from commit 6769e39)
Fixes a bug where only pack environments created during constraint would be usable during solution application, everything else would create a new environment that would produce pack elements with new UUIDs which cases issues during SILGen.
The constraint solver would supply its own version of the function that can check for pack expansion type variables as well. (cherry picked from commit 5c2f77c)
This flag indicates that a type variable could only be bound to PackExpansionType and nothing else. (cherry picked from commit 6437531)
Models `PackExpansionType` as a type variable that can only bind to `PackExpansionType` and `expansion of` constraint that connects expansion variable to its pattern, shape types. (cherry picked from commit 39c2bbb)
…solved pack expansions If a pattern type of a pack expansion doesn't have all of the "pack capable" type variables bound, we don't know what the structure is yet and expansion cannot be flattened. (cherry picked from commit c7ef47d)
…hile matching (cherry picked from commit ca534ef)
A pack expansion type variable gets bound to its original pattern type when solver can infer a contextual type for it. This makes sure that pack expansion types are always matched via `matchTypes` without `simplifyType` involvement which can expand them prematurely. (cherry picked from commit c130351)
Even if both sides are pack expansion variables they cannot be merged because merging of them means merging of pattern and shape types as well, which is easier to do when one of both sides are bound. (cherry picked from commit 5340725)
…nstraints Tuple types cannot be matched until all pack expansion variables are resolved, the same is applicable to `shape of` constraints because the structure of the pack is not fully resolved in such cases. (cherry picked from commit d7c3208)
…olved (cherry picked from commit b0abb7f)
…expansion variables `TypeBase::constainsPackExpansionType` cannot handle this because it leaves in AST. (cherry picked from commit 0738780)
…are involved The constraint solver has its own version of this method which know how to deal with pack expansion type variables. (cherry picked from commit b4ba68a)
…olved pack expansions This handles situations like `Int <conv> (Int, (_: $T_exp)` or `String arg conv (_: $T_exp)`. The matching has to be delayed because the structure of the tuple type is not known until `$T_exp` (which represents a pack expansion type) is resolved. (cherry picked from commit 2ebade1)
…pe variables Such type variables always depend on pack expansion variables. (cherry picked from commit 8a39f3f)
…roduce pattern type The `transformWithPosition` would handle its flattening. (cherry picked from commit f4a082d)
…iable is flattened This is effectively the same as check `transformWithPosition` but handles pack expansion type variables. (cherry picked from commit 5985275)
…sion variables Pack expansion type variable can only ever have one binding which is handled by \c resolvePackExpansion. There is no need to iterate over other bindings here because there is no use for contextual types (unlike closures that can propagate contextual information into the body). (cherry picked from commit 62b6d01)
…open pack expansion types Replace all `PackExpansionType` with a special type variable which would be resolved once the solver determines that there is enough contextual information. (cherry picked from commit 218ccb1)
… with pack expansions Pack expansion flattening could result in lose of tuple structure or introduce a single element tuples (which are effectively parens), to aid in matching `matchTypes` should introduce/maintain tuples on both sides of the comparison until the structure is known. (cherry picked from commit cc2b6ce)
…lement (cherry picked from commit ed23aec)
`openType` didn't need a locator before it was simply replacing generic parameters with corresponding type variables but now, with opening of pack expansions types, a locator is needed for pack expansion variables. (cherry picked from commit fd060f5)
…raint simplification It's only safe to infer element type from `PackElementOf` constraint when pattern type is fully resolved (because it can have pack element archetypes which should be mapped out of context), the same applies to the pattern type inference as well. Since constraints are re-activated every time a referenced type variable is bound, simplication logic can act as inference source by decaying into `Equal` constraints where pattern/element type are resolved via surrounding information first. (cherry picked from commit 9a395f0)
…expansions Just like in any other position, let's restore unresolved type variables that represent generic parameters to their generic parameter type when they are found in a pack expansion pattern type. (cherry picked from commit 9365211)
…element tuples If solver had to introduce an unlabeled single-element tuple around contextual type, let's strip it and fix as a regular contextual mismatch (instead of a tuple mismatch) because this action should be transparent to diagnostics. (cherry picked from commit 38ee650)
… holes If type variable that is being replaces allowed holes, the new one should not lose this property. (cherry picked from commit 943ef19)
If there are explicit generic arguments that fully resolves the pack expansion, let's bind opened pack expansion to its contextual type early (while resolving pack expansion variable), doing so helps with performance and diagnostics. (cherry picked from commit cbfec20)
The constraint takes two pack types and makes sure that their reduced shapes are equal. This helps with diagnostics because constraint has access to the original pack expansion pattern types. (cherry picked from commit bbe305c)
…ed to arguments Suggest to drop tuples, synthesized or remove extraneous arguments based on pack shape mismatches. (cherry picked from commit 03f88a0)
If diagnostic references a `Pack{repeat ...}` unwrap it to underlying
pattern.
(cherry picked from commit b5aae06)
…ack expansion (cherry picked from commit b9ef2ca)
…pect a tuple argument
Diagnose situation when a single argument to tuple type is passed to
a value pack expansion parameter that expects distinct N elements:
```swift
struct S<each T> {
func test(x: Int, _: repeat each T) {}
}
S<Int, String>().test(x: 42, (2, "b"))
```
(cherry picked from commit c74824e)
…at expects individual arguments (cherry picked from commit 3006f55)
Propagating holes to the shape helps avoid spurious diagnostics about same-shape requirement failures. Resolves: rdar://107675464 (cherry picked from commit 0db6746)
Situations like `repeat x` where `x` is `Int` where pack expansion expression doesn't have any pack references. (cherry picked from commit d8c8a39)
…erences (cherry picked from commit cb2fdd9)
Detect that pack expansion expression doesn't have any pack references during constraint generation. Resolves: rdar://107835215 (cherry picked from commit bff6a89)
… pattern (cherry picked from commit 70eeccb)
(cherry picked from commit b081bdb)
Introduce `ConstraintSystem::recordTypeVariablesAsHoles` as a standard way to record that unbound type variables found in a type are holes in the given constraint system. (cherry picked from commit 8a26df8)
(cherry picked from commit 20d7642)
When `matchTypesBindTypeVar` detects invalid pack reference it should reset the type to a placeholder and allow binding to go through, otherwise, if binding comes from inference, returning without binding would create an infinite loop because type variable would perpetually be the best choice to attempt. (cherry picked from commit 3714c48)
xedin
force-pushed
the
sema-variadic-fixes-anthology-5.9
branch
from
122dba3 to
554f2a4
Compare
|
@swift-ci please test |
hborla
approved these changes
May 3, 2023
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.
Cherry-pick of #65165, #65445, #65125, #64907, #65366
Explanation:
same-shapeconstraint to match shape types of packs and aid with diagnostics;Scope: Expressions that use variadic generics feature.
Main Branch PR: [CSSolver] Add recorded pack expansion environments to solutions #65165, [Diagnostics] Suppress unused expression warning if result is discard… #65445, [ConstraintSystem] Model pack expansion types via type variables #65125, [CSSimplify] Prevent invalid pack references from causing infinite loops #64907, [CSSolver] Fix a crash in diagnostics related to pattern matching #65366
Resolves: rdar://107996926, rdar://107835125, rdar://107675464, rdar://107429079, rdar://107835215, rdar://107835086, rdar://108064941
Risk: Medium
Reviewed By: @hborla
Testing: Added regression test-cases to the suite.