Improve and fix diagnostics of exhaustiveness checking#80104
Improve and fix diagnostics of exhaustiveness checking#80104bors merged 7 commits intorust-lang:masterfrom
Conversation
d606216 to
616ba9f
Compare
|
Oh well, that's why I shouldn't push a PR just before sleep ^^. I thought a perf impact was unavoidable but it wasn't. I've edited the OP to reflect that. |
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. |
|
⌛ Trying commit 616ba9f9f7f5845777a36e1a41a515e6c33a8776 with merge 14cfbb5782b26a8629319961f978f42d37deff26... |
|
☀️ Try build successful - checks-actions |
|
Queued 14cfbb5782b26a8629319961f978f42d37deff26 with parent bdd0a78, future comparison URL. @rustbot label: +S-waiting-on-perf |
|
Finished benchmarking try commit (14cfbb5782b26a8629319961f978f42d37deff26): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
|
.6% regression on instructions for match-stress-enum-check (in check_match, as expected). Personally I think the diagnostic improvements are worth it. |
`SpanSet` is heavily inspired from `DefIdForest`.
This is elegant but a bit of a perf gamble. That said, or-patterns rarely have many branches and it's easy to optimize or revert if we ever need to. In the meantime simpler code is worth it.
616ba9f to
cefcadb
Compare
|
Looks good, thanks! @bors r+ |
|
📌 Commit cefcadb has been approved by |
|
⌛ Testing commit cefcadb with merge 30bf3f1f34da6ffc50c4df5abf6dd8d2aa5a3e73... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
|
Looks spurious to me. @bors retry |
|
☀️ Test successful - checks-actions |
Identify unreachable subpatterns more reliably In rust-lang#80104 I used `Span`s to identify unreachable sub-patterns in the presence of or-patterns during exhaustiveness checking. In rust-lang#80501 it was revealed that `Span`s are complicated and that this was not a good idea. Instead, this PR identifies subpatterns logically: as a path in the tree of subpatterns of a given pattern. I made a struct that captures a set of such subpatterns. This is a bit complex, but thankfully self-contained; the rest of the code does not need to know anything about it. Fixes rust-lang#80501. I think I managed to keep the perf neutral. r? `@varkor`
Primarily, this fixes #56379. This also fixes incorrect interactions between or-patterns and slice patterns that I discovered while working on #56379. Those two examples show the incorrect diagnostics:
I did not measure any perf impact. However, I suspect that
616ba9fshould have a negative impact on large or-patterns. I'll see what the perf run says; I have optimization ideas up my sleeve if needed.EDIT: I initially had a noticeable perf impact that I thought unavoidable. I then proceeded to avoid it x)
r? @varkor
@rustbot label +A-exhaustiveness-checking