[WIP] Move ExprPattern type-checking into the solver #63963
Closed
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
hamishknight
force-pushed
the
patte-reduction
branch
4 times, most recently
from
5800450 to
07a2529
Compare
hamishknight
force-pushed
the
patte-reduction
branch
from
07a2529 to
ee3934a
Compare
hamishknight
force-pushed
the
patte-reduction
branch
from
ee3934a to
43583f3
Compare
hamishknight
force-pushed
the
patte-reduction
branch
from
43583f3 to
e4df0ed
Compare
The TypedPattern and IsPattern constraints were incorrectly written, with conversions propagating out of the patterns, when really conversions ought to propagate into patterns. In any case, it seems like we really want equality here. Fix the constraints to use equality, and have the cast constraint operate on the external pattern type instead of the subpattern type.
Order them such that if they were changed to conversions, they would be sound. This shouldn't make a difference, but unfortunately it turns out pattern equality is not symmetric. As such, tweak the pattern equality logic to account for the reversed types. This allows us to remove a special case from function matching.
This shouldn't be necessary, we should be able to solve with type variables instead. This makes sure we don't end up with weird special cases that only occur when an external type is present.
Push the only null case that can occur up into the caller.
We should never CSGen a null Type for patterns.
…rceRange For an external property wrapper, there may not be a pattern here. I believe this should only be hit during `-debug-constraints` or if there's a too complex error (which I'm not sure is possible to produce in this case), so no test.
Instead of walking the single ASTNode from the target, walk all AST nodes associated with the target to find the completion expr. This is needed to find the completion expr in a pattern for an initialization target.
Previously we would wait until CSApply, which would trigger their type-checking in `coercePatternToType`. This caused a number of bugs, and hampered solver-based completion, which does not run CSApply. Instead, form a conjunction of all the ExprPatterns present, which preserves some of the previous isolation behavior (though does not provide complete isolation). We can then modify `coercePatternToType` to accept a closure, which allows the solver to take over rewriting the ExprPatterns it has already solved. This then sets the stage for the complete removal of `coercePatternToType`, and doing all pattern type-checking in the solver.
hamishknight
force-pushed
the
patte-reduction
branch
from
e4df0ed to
4bb6d0a
Compare
|
@swift-ci please test |
|
@swift-ci please SourceKit stress test |
|
Continuing on #64280 |
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.
No description provided.