match exhaustiveness: Expand or-patterns as a separate step #128015
Conversation
rustbot
added
S-waiting-on-review
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
…try> match exhaustiveness: Expand or-patterns as a separate step To compute exhaustiveness, we must expand or-patterns. Previously, we expanded them at the same time that we pushed patterns into the matrix. This made it harder to track pattern reachability, because the or-pattern itself would never show up in the matrix so we had to recover missing information. This PR changes that: we no longer expand or-patterns as we push them into the matrix. Instead, if we find an or-pattern in the matrix we expand them in a step very much like the specialization we already do. This simplifies a bunch of things, and will greatly simplify the implementation of rust-lang#127870. r? `@compiler-errors`
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (5f57f25): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 771.36s -> 771.627s (0.03%) |
rustbot
removed
the
S-waiting-on-perf
|
@bors r+ |
bors
added
S-waiting-on-bors
exhaustiveness: Explain why a given pattern is considered unreachable This PR tells the user why a given pattern is considered unreachable. I reused the intersection information we were already computing; even though it's incomplete I convinced myself that it is sufficient to always get a set of patterns that cover the unreachable one. I'm not a fan of the diagnostic messages I came up with, I'm open to suggestions. Fixes rust-lang#127870. This is also the other one of the two diagnostic improvements I wanted to do before rust-lang#122792. Note: the first commit is rust-lang#128015, the second is an unrelated drive-by tweak. r? `@compiler-errors`
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (49649bf): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 770.647s -> 772.806s (0.28%) |
To compute exhaustiveness, we must expand or-patterns. Previously, we expanded them at the same time that we pushed patterns into the matrix. This made it harder to track pattern reachability, because the or-pattern itself would never show up in the matrix so we had to recover missing information.
This PR changes that: we no longer expand or-patterns as we push them into the matrix. Instead, if we find an or-pattern in the matrix we expand them in a step very much like the specialization we already do. This simplifies a bunch of things, and should greatly simplify the implementation of #127870.
r? @compiler-errors