Repository navigation
overlapping_range_endpoints false positive #117648
Description
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 defaultDesired 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)
Reacted by Scott Steele, Jaanus Varus, Rodrigo Batista de Moraes, Yerkebulan Tulibergenov, Dannii Willis, spendemJD and Adam C. Foltzer
Activity
Nadrieril commentedon Dec 19, 2023
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 | 0instead of..=0. I won't argue that this is particularly clearer in your case 😅.I won't close this as
wontfixuntil 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 commentedon Dec 28, 2023
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
allowfor matches of compound structures will mean a reduction in correctness checks vs 1.74.1.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 commentedon Dec 28, 2023
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 commentedon Dec 28, 2023
This turned out to be pretty easy to implement! (#119396) Let's see what the perf report says.
Auto merge of rust-lang#119396 - Nadrieril:intersection-tracking, r=<…
Auto merge of rust-lang#119396 - Nadrieril:intersection-tracking, r=<…
Auto merge of rust-lang#119396 - Nadrieril:intersection-tracking, r=<…
Nadrieril commentedon Jan 1, 2024
The perf report reports a perf improvement x) I'm glad I tried, the PR will likely get merged soon.
Auto merge of rust-lang#119396 - Nadrieril:intersection-tracking, r=W…
Nadrieril commentedon Jan 12, 2024
Fixed by #119396 🎉