-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add check for overlapping ranges to unreachable patterns lint #64007
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
6bb131c
to
cd6d7ba
Compare
cd6d7ba
to
2731c02
Compare
I'll look at the code more closely later, but I think this should be pulled out into its own lint, as I think there are legitimate reasons to want overlapping ranges (though overlapping by a single element seems less intentional). |
This comment has been minimized.
This comment has been minimized.
ea4ab95
to
4a8d83e
Compare
Conclusions from the lang team meeting:
Because of that, we think this should be in clippy. |
I feel strongly that this shouldn't be My interpretation here is that this needs to be heuristic-heavy, so it being in clippy sounds fine. But if there's some obvious simple heuristic that's essentially always correct I have no objection to having it in the compiler. (Maybe something like "the fix is just to change a literal to a different literal".) |
I could restrict this new lint to single element overlap ( |
I think going for the single element overlap (just for ranges) is something I'd be OK with in rustc. |
This comment has been minimized.
This comment has been minimized.
On September 5, 2019 1:32:55 PM PDT, Mazdak Farrokhzad ***@***.***> wrote:
I think going for the single element overlap (just for ranges) is
something I'd be OK with in rustc.
Likewise. Good idea.
|
ping from triage @estebank, any update after the reviewers' comment? |
Pinging again from triage. |
Hello from triage: Thank you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Centril should this be changed to only lint on single element overlap?
Yes, let's start conservative for now with the consensus that is expressed in the PR discussion and we can consider expanding the scope later on. Possibly also file an issue for considering the scope-expansion and tag T-lang (maybe also dump the existing code there for keep-sakes). |
c19d1a2
to
593cdcc
Compare
@bors r+ |
📌 Commit 593cdcc has been approved by |
…tthewjasper Add check for overlapping ranges to unreachable patterns lint Fix rust-lang#63987.
Rollup of 5 pull requests Successful merges: - #64007 (Add check for overlapping ranges to unreachable patterns lint) - #65192 (Use structured suggestion for restricting bounds) - #65226 (BTreeSet symmetric_difference & union optimized) - #65448 (rustc_codegen_ssa: remove some unnecessary Box special-casing.) - #65505 (Rc: value -> allocation) Failed merges: r? @ghost
Refactor integer range handling in the usefulness algorithm Integer range handling had accumulated a lot of debt. This cleans up a lot of it. In particular this: - removes unnecessary conversions between `Const` and `u128`, and between `Constructor` and `IntRange` - clearly distinguishes between on the one hand ranges of integers that may or may not be matched exhaustively, and on the other hand ranges of non-integers that are never matched exhaustively and are compared using Const-based shenanigans - cleans up some overly complicated code paths - generally tries to be more idiomatic. As a nice side-effect, I measured a 10% perf increase on `unicode_normalization`. There's one thing that I feel remains to clean up: the [overlapping range check](#64007), which is currently quite ad-hoc. But that is intricate enough that I'm leaving it out of this PR. There's also one little thing I'm not sure I understand: can `try_eval_bits` fail for an integer constant value in that code ? What would that mean, and how do I construct a test case for this possibility ?
Refactor integer range handling in the usefulness algorithm Integer range handling had accumulated a lot of debt. This cleans up a lot of it. In particular this: - removes unnecessary conversions between `Const` and `u128`, and between `Constructor` and `IntRange` - clearly distinguishes between on the one hand ranges of integers that may or may not be matched exhaustively, and on the other hand ranges of non-integers that are never matched exhaustively and are compared using Const-based shenanigans - cleans up some overly complicated code paths - generally tries to be more idiomatic. As a nice side-effect, I measured a 10% perf increase on `unicode_normalization`. There's one thing that I feel remains to clean up: the [overlapping range check](#64007), which is currently quite ad-hoc. But that is intricate enough that I'm leaving it out of this PR. There's also one little thing I'm not sure I understand: can `try_eval_bits` fail for an integer constant value in that code ? What would that mean, and how do I construct a test case for this possibility ?
Refactor integer range handling in the usefulness algorithm Integer range handling had accumulated a lot of debt. This cleans up a lot of it. In particular this: - removes unnecessary conversions between `Const` and `u128`, and between `Constructor` and `IntRange` - clearly distinguishes between on the one hand ranges of integers that may or may not be matched exhaustively, and on the other hand ranges of non-integers that are never matched exhaustively and are compared using Const-based shenanigans - cleans up some overly complicated code paths - generally tries to be more idiomatic. As a nice side-effect, I measured a 10% perf increase on `unicode_normalization`. There's one thing that I feel remains to clean up: the [overlapping range check](#64007), which is currently quite ad-hoc. But that is intricate enough that I'm leaving it out of this PR. There's also one little thing I'm not sure I understand: can `try_eval_bits` fail for an integer constant value in that code ? What would that mean, and how do I construct a test case for this possibility ?
Fix #63987.