diff options
author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2020-04-08 18:52:41 +0100 |
---|---|---|
committer | GitHub <[email protected]> | 2020-04-08 18:52:41 +0100 |
commit | 779555c1beac90f633c01a773558c4007c99c97f (patch) | |
tree | 115e9461072029b942dbb28f35a73fbe3ae34fec /crates/ra_assists | |
parent | 4762c6d9c66dc1b6be9b9010dbe787ef8d69530a (diff) | |
parent | 36c110ee096d46b02aa2a5adfaf138cd8c3872a7 (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_assists')
0 files changed, 0 insertions, 0 deletions