Along the way, we also implement a handful of diagnostics improvements
and fixes, particularly with respect to the special handling of `||` in
place of `|` and when there are leading verts in function params, which
don't allow top-level or-patterns anyway.
Identify unreachable subpatterns more reliably
In https://github.com/rust-lang/rust/pull/80104 I used `Span`s to identify unreachable sub-patterns in the presence of or-patterns during exhaustiveness checking. In https://github.com/rust-lang/rust/issues/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 https://github.com/rust-lang/rust/issues/80501. I think I managed to keep the perf neutral.
r? `@varkor`
or_patterns: implement :pat edition-specific behavior
cc #54883 `@joshtriplett`
This PR implements the edition-specific behavior of `:pat` wrt or-patterns, as determined by the crater runs and T-lang consensus in https://github.com/rust-lang/rust/issues/54883#issuecomment-745509090.
I believe this can unblock stabilization of or_patterns.
r? `@petrochenkov`
If a symbol name can only be imported from one place for a type, and
as long as it was not glob-imported anywhere in the current crate, we
can trim its printed path and print only the name.
This has wide implications on error messages with types, for example,
shortening `std::vec::Vec` to just `Vec`, as long as there is no other
`Vec` importable anywhere.
This adds a new '-Z trim-diagnostic-paths=false' option to control this
feature.
On the good path, with no diagnosis printed, we should try to avoid
issuing this query, so we need to prevent trimmed_def_paths query on
several cases.
This change also relies on a previous commit that differentiates
between `Debug` and `Display` on various rustc types, where the latter
is trimmed and presented to the user and the former is not.
Previously errors were sorted by Symbol index instead of the string. The
indexes are not the same between architectures because Symbols for
architecture extensions (e.g. x86 AVX or RISC-V d) are interned before
the source file is parsed. RISC-V's naming of extensions after single
letters led to it having errors sorted differently for test cases using
single letter variable names. Instead sort the errors by the Symbol
string so that it is stable across architectures.
non-exhastive diagnostic: add note re. scrutinee type
This fixes https://github.com/rust-lang/rust/issues/67259 by adding a note:
```
= note: the matched value is of type &[i32]
```
to non-exhaustive pattern matching errors.
r? @varkor @estebank
check_binding_alt_eq_ty: improve precision wrt. `if let`
Follow up to https://github.com/rust-lang/rust/pull/69452 -- this tweaks the `check_binding_alt_eq_ty` logic wrt. wording so that `if let` doesn't include "in this arm" (because there can only ever be one arm).
r? @estebank
resolve, inconsistent binding mode: tweak wording
Now that we can have e.g. `let Ok(x) | Err(x) = res;`, it's no longer appropriate to refer to "the same *match arm*", so let's tweak the wording.
r? @estebank
typeck: clarify def_bm adjustments & add tests for or-patterns
Clarify the adjustment algorithm for the expected type / default binding-modes when type checking patterns with more documentation and tweaks that make the algorithm more independent of the pattern forms.
Also resolve the FIXME noted for or-patterns by deciding that the current implementation is correct, noting the rationale and adding tests for the current implementation.
cc https://github.com/rust-lang/rust/issues/54883
r? @oli-obk @varkor
