-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve and fix diagnostics of exhaustiveness checking #80104
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
616ba9f
should 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