overlapping_range_endpoints false positive

[benluelo]

Code

match (0i8, 0i8) {
    (0, _) => {}
    // change either of these to not overlap and it will error
    (..=-1, ..=0) => {}
    (1.., 0..) => {}
    (1.., ..=-1) | (..=-1, 1..) => {}
}

Current output

warning: multiple patterns overlap on their endpoints
 --> src/main.rs:6:15
  |
5 |         (..=-1, ..=0) => {}
  |                 ---- this range overlaps on `0_i8`...
6 |         (1.., 0..) => {}
  |               ^^^ ... with this range
  |
  = note: you likely meant to write mutually exclusive ranges
  = note: `#[warn(overlapping_range_endpoints)]` on by default

Desired output

no output, pattern is exhaustive. addressing the warning causes an error as it is no longer exhaustive.

Rationale and extra context

No response

Other cases

No response

Anything else?

this is only occurring on nightly (at least as of 2023-11-01, i haven't tested anything sooner)

[Nadrieril]

Yep, that's somewhat intentional. The true reason is that detecting this properly would require more work from exhaustiveness checking, which is a performance cost I predicted we wouldn't want to pay. That said I haven't actually measured anything so I could be wrong.

The rationalization is that forcing the user to clarify intent could be worth it for future readers. One way to clarify would be to write ..0 | 0 instead of ..=0. I won't argue that this is particularly clearer in your case 😅.

I won't close this as wontfix until we can decide based on perf measurements, but I also don't have the intention to do this work myself so this may not be fixed for a long while sorry.

[scooter-dangle]

This is showing up in a way that will cause confusion for devs in our codebase. Would it be possible to move this warning in its current form to a clippy lint given that it has easily confirmed false positives?

EDIT: I posted too quickly. Hadn't realized that this was a modification of an existing warning rather than a totally new warning. Same resolution would be preferred (move FP-prone portion to a Clippy lint if eliminating FPs isn't feasible at the moment), although maybe splitting out the behavior of the warning is more labor-intensive than just moving it in its entirety?

The addition of false positives to a previously reliable warning is unfortunate from a workaround perspective since an allow for matches of compound structures will mean a reduction in correctness checks vs 1.74.1.

One way to clarify would be to write ..0 | 0 instead of ..=0. I won't argue that this is particularly clearer in your case 😅.

Note that that workaround isn't available on stable.

---

Other note: I wish I had the time + knowledge to help with this. Sorry to only raise problems and not offer help on an actual fix 😞

[Nadrieril]

It's unfortunately not possible to split off the FP-prone portion. The whole lint is FP-prone from the way it is currently computed :/

[Nadrieril]

This turned out to be pretty easy to implement! (#119396) Let's see what the perf report says.

[Nadrieril]

The perf report reports a perf improvement x) I'm glad I tried, the PR will likely get merged soon.