aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_syntax/test_data/parser/ok/0019_enums.rast
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2020-04-08 18:52:41 +0100
committerGitHub <[email protected]>2020-04-08 18:52:41 +0100
commit779555c1beac90f633c01a773558c4007c99c97f (patch)
tree115e9461072029b942dbb28f35a73fbe3ae34fec /crates/ra_syntax/test_data/parser/ok/0019_enums.rast
parent4762c6d9c66dc1b6be9b9010dbe787ef8d69530a (diff)
parent36c110ee096d46b02aa2a5adfaf138cd8c3872a7 (diff)
Merge #3884
3884: Match check fix missing pattern panic r=flodiebold a=JoshMcguigan As reported by @cynecx, match arm exhaustiveness checking could panic when tuple enums were missing their pattern. This was reported in the comments of #3706. This fixes the panic, and adds a similar test to ensure tuples don't have this problem. It turns out malformed tuple patterns are caught in the "type check" outside the `is_useful` function, while malformed enum tuple patterns are not. This makes sense to me in hindsight, since the type checker can tell that an enum is the right type even if it is missing its internal pattern, but a tuple (non-enum) just becomes a different type if it is "missing" its pattern. This discrepency is why we report a diagnostic in the tuple case (because all arms are filtered out, so there are missing arms), but not in the enum tuple case (because we return an `Err(MalformedMatchArm)` from `is_useful`). I don't think this is that big of a deal, because in both cases this is malformed code and there should eventually be a `MalformedMatchArm` diagnostic or similar. But perhaps we should change things so that if any arm fails the type check we skip the entire diagnostic? That would at least make these two cases behave in the same way. @flodiebold Co-authored-by: Josh Mcguigan <[email protected]>
Diffstat (limited to 'crates/ra_syntax/test_data/parser/ok/0019_enums.rast')
0 files changed, 0 insertions, 0 deletions