Refactor pattern-matching usefulness algorithm #65160
Commits on Oct 18, 2019
-
-
-
Clarify and fix the explanation of the algorithm
There was a bit of confusion between individual patterns and lists of patterns, and index mismatches linked to that. This introduces a vocabulary of "pattern-stacks" to provide a clearer mental model of what is happening. This also adds examples.
-
-
-
Remove duplicate logic in compute_missing_constructors
This is equivalent to the previous code in terms of performance. The expensive path is clearly identical. The fast path is also the same, because in both cases we loop until we get a non-empty `refined_ctors`, and then stop there. So the new code doesn't compute anything more than the previous did.
-
-
-
-
-
-
-
-
-
Rework the exhaustiveness algorithm to better integrate meta-construc…
…tors This is strictly a refactoring: the new algorithm does exactly the same work as the previous one. However, it replaces the ad-hoc handling of ranges and slice patterns with a unified approach, using meta-constructors. This should improve both code legibility and future extensibility.
-
-
-
-
Match constructor first instead of type first in various functions
Needed since there may now be meta-constructors for the given type. Also implement the trivial MissingConstructors cases for some of those functions.
-
-
-
-
-
-
-
-
-
-
Gather together usefulness tests
I took most tests that were testing only for match exhaustiveness, pattern refutability or match arm reachability, and put them in the same test folder.
-
-
-
-
Use Wildcard instead of MissingConstructors when relevant
This both simplifies the missing constructors codepath and exactly matches what we want for witness construction. So this behaviour of witness construction isn't an ad-hoc tweak anymore, it also makes semantic sense.
-
-
-
-
Extract constructor_intersects_pattern function
This reverses changes from rust-lang#65089, but I need this temporarily for rebase to be tractable.
-
-
-
-
-
-
-
-
Make exhaustiveness error message more consistent for slice patterns
Now it doesn't depend on the rather arbitrary (from the user's point of view) max_slice_length limit. When slice_patterns is not enabled, and the missing pattern is e.g. `[_, _, ..]`, the message will report that `[_, _]` is missing. Previously, it would sometimes report a few more missing patterns but of course never all of them. When the feature is enabled, the message correctly reports that `[_, _, ..]` is missing.
-
-
-
-
-
Note that where we previously ran `max_slice_len` with input having not only matrix_head_ctors but also all of v_constructors. Now we run it on matrix_head_ctors and one constructor of v_constructors at a time. In the presence of or-patterns, those two things might differ. However the new behaviour is still valid with regards to the specified semantics of split_meta_constructor.
-
-
Splitting variable-length slices now respects the required invariant
The previous behaviour did not respect the invariant specified in the description of the algorithm. As a nice side-effect, exhaustiveness errors have improved when slice_patterns is enabled; they now capture all missing lengths instead of the shortest. Note: this changes diagnostics, but only when slice_patterns is enabled.
-
It was introduced to carry max_slice_length so we don't need it anymore.
-
Several comments were leftover from before the rework of the algorithm and didn't make sens anymore.
-
This makes the conversions from/to Const better localized. In particular, eval_bits only happens in IntRange::from_ctor.
-
-
-
-
Move range exhaustiveness check to IntRange::intersection
Only IntRange needs to worry about range exhaustiveness really.
-
-
-
-
-
-
Clarify why the naive algorithm may not terminate
As suggested by arielb1 rust-lang#65160 (review)
-
-
-
-
-
-
Compute constructors on PatStack construction
All the constructed PatStacks end up having `head_ctors` called on them, so this does not unnecessarily precompute anything.
-
Stop checking that cached constructors are valid. Avoid cloning constructors when not necessary.
-
-
Don't use SmallVec when we could use Option
This reverts some of the or-patterns future-proofing, for the sake of performance.
-
