mirror of
https://github.com/rust-lang/rust.git
synced 2024-11-26 16:54:01 +00:00
1a086e49f1
Exhaustiveness: Improve complexity on some wide matches https://github.com/rust-lang/rust/issues/118437 revealed an exponential case in exhaustiveness checking. While [exponential cases are unavoidable](https://compilercrim.es/rust-np/), this one only showed up after my https://github.com/rust-lang/rust/pull/117611 rewrite of the algorithm. I remember anticipating a case like this and dismissing it as unrealistic, but here we are :'). The tricky match is as follows: ```rust match command { BaseCommand { field01: true, .. } => {} BaseCommand { field02: true, .. } => {} BaseCommand { field03: true, .. } => {} BaseCommand { field04: true, .. } => {} BaseCommand { field05: true, .. } => {} BaseCommand { field06: true, .. } => {} BaseCommand { field07: true, .. } => {} BaseCommand { field08: true, .. } => {} BaseCommand { field09: true, .. } => {} BaseCommand { field10: true, .. } => {} // ...20 more of the same _ => {} } ``` To fix this, this PR formalizes a concept of "relevancy" (naming is hard) that was already used to decide what patterns to report. Now we track it for every row, which in wide matches like the above can drastically cut on the number of cases we explore. After this fix, the above match is checked with linear-many cases instead of exponentially-many. Fixes https://github.com/rust-lang/rust/issues/118437 r? `@cjgillot` |
||
|---|---|---|
| .. | ||
| assembly | ||
| auxiliary | ||
| codegen | ||
| codegen-units | ||
| coverage | ||
| coverage-run-rustdoc | ||
| debuginfo | ||
| incremental | ||
| mir-opt | ||
| pretty | ||
| run-make | ||
| run-make-fulldeps | ||
| run-pass-valgrind | ||
| rustdoc | ||
| rustdoc-gui | ||
| rustdoc-js | ||
| rustdoc-js-std | ||
| rustdoc-json | ||
| rustdoc-ui | ||
| ui | ||
| ui-fulldeps | ||
| COMPILER_TESTS.md | ||