Left side of Or-Patterns is not marked as useless even when covered completely by right side

Code

match 0 {
    0 | _ => {}
}

Current output

None

Desired output

Something like

warning: useless pattern
 --> src/lib.rs:X:Y
  |
3 |         0 | _ => {}
  |         _   ^ covers all values the left side of the or pattern covers
  |         |
  |         does not influence result of match
  |
  = note: `#[warn(unreachable_patterns)]` (part of `#[warn(unused)]`) on by default

Rationale and extra context

rustc warns for patterns like _ | 0 where the right-hand side of the or pattern is useless, but does not warn for patterns like 0 | _ where the left-hand side is useless.
Patterns like 0 | _ indicate a likely bug for the same reason patterns like _ | 0 do, so they should also get a warning.

Unfortunately, the terminology used in the current warnings of unreachable patterns does not strictly apply to the 0 | _ case. Here, the pattern 0 is not unreachable, but it is useless. It never affects the result of the match in any way. So how exactly this would slot into the unreachable_patterns warning is not entirely clear.

I believe the existing pattern usefulness algorithm could relatively easily be adapted to check this case.

Note: If bindings are introduced, the order in which patterns are matched can become relevant. Consider the pattern (0, x) | (x, _). Here, it absolutely matters for the value of x whether the left pattern is matched, even though it is entirely covered by the right pattern. So there needs to be some analysis of potential bindings to avoid false positives.

Note: clippy warns for 0 | _, but there are just slightly more complicated cases that clippy cannot analyse deeply enough to warn about. The exhaustiveness and usefulness algorithm in the compiler would be better suited to properly analyse these cases. Even 0 | 0.. defeats the clippy analysis.

Other cases

Rust Version

$ rustc --version --verbose
rustc 1.97.1 (8bab26f4f 2026-07-14)
binary: rustc
commit-hash: 8bab26f4f68e0e26f0bb7960be334d5b520ea452
commit-date: 2026-07-14
host: x86_64-unknown-linux-gnu
release: 1.97.1
LLVM version: 22.1.6

Anything else?

Full disclosure, I reproduced this on the rust playground with latest stable (1.97.1) and latest nightly, and I don't know how to get the verbose rust version string from playground. So the host in the rust version field of this issue might not match exactly with the environment I reproduced it in, but that really should not matter.

Reproduce the report's match example in src/lib.rs and start with the compiler's pattern usefulness algorithm described in the issue. Compare it with the existing _ | 0 behavior, then investigate binding cases such as (0, x) | (x, _). Done means useless left alternatives like 0 | _ are diagnosed without false positives for bindings, including coverage cases such as 0 | 0..