[Constraint system] Generate constraints from patterns #29879
Conversation
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
DougGregor
force-pushed
the
constraint-system-patterns
branch
from
f53a25d to
03b8217
Compare
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
DougGregor
force-pushed
the
constraint-system-patterns
branch
from
03b8217 to
43f57a8
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
We’ll need this to generate constraints for statement conditions within the constraint system. This is unused boilerplate at the moment.
Generate a checked-cast constraint for an “is” pattern, which otherwise doesn’t change the type. This is hard to validate because checked-cast constraints never actually fail.
For typed patterns, the sub pattern type must be convertible to the type provided to the pattern.
Generate a complete set of constraints for EnumElement patterns, e.g.,
case let .something(x, y)
Most of the complication here comes from the implicit injection of optionals,
e.g., this case can be matched to an optional of the enum type of which
`something` is a member. To effect this change, introduce a locator for
pattern matching and use it to permit implicit unwrapping during member
lookup without triggering an error.
Note also labels are dropped completely when performing the match,
because labels can be added or removed when pattern matching. Label
conflict are currently diagnosed as part of coercePatternToType, which
suffices so long as overloading cases based on argument labels is not
permitted.
The primary observable change from this commit is in diagnostics: rather
than diagnostics being triggered by `TypeChecker::coercePatternToType`,
diagnostics for matching failures here go through the diagnostics machinery
of the constraint solver. This is currently a regression, because
there are no custom diagnostics for pattern match failures within the
constraint system. This regression will be addressed in a subsequent
commit; for now, leave those tests failing.
Extend the constraint system’s diagnostics with specific handling for matching an enum element pattern that has a subpattern (i.e., to capture associated values) against an enum case that does not have any associated value. This brings diagnostics for the new code path on par with the existing diagnostics of coercePatternToType.
DougGregor
force-pushed
the
constraint-system-patterns
branch
from
06ead94 to
d607d3a
Compare
|
@swift-ci please smoke test |
|
@swift-ci please test compiler performance |
|
@swift-ci please test source compatibility |
|
@swift-ci please smoke test |
|
@swift-ci please test compiler performance |
|
@swift-ci please test source compatibility |
|
Compilation-performance test failed |
SE-0110 strikes again!
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
There was a problem hiding this comment.
Looks great! Changes in constraint generation make we wonder whether it would make sense to extend visit* methods in Constraint{Walker, Generator} to all of these different patterns too (e.g. visit*Pattern(...)), instead of using a giant switch statement in getTypeForPattern? It seems like this way constraint generation won't need any special handling and type recording (via setType) which is correctly happening.
Maybe! My upcoming PR (once this one finally lands) has to start passing down more state information in |
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
1 similar comment
|
@swift-ci please test source compatibility |
|
@swift-ci please smoke test macOS |
Generate constraints from the various forms of patterns, so that the well-formedness of the
pattern itself is established while solving the constraint system. Within this pull request:
?)as).caseName(sub pattern))BooltypeThese constraints are currently used when type checking
if caseandguard case, but not themore general
switchcases (yet).