Skip to content
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

Merged
merged 10 commits into from
Oct 19, 2019

Conversation

estebank
Copy link
Contributor

Fix #63987.

@rust-highfive
Copy link
Collaborator

r? @matthewjasper

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 29, 2019
@estebank estebank force-pushed the overlapping-patterns branch from 6bb131c to cd6d7ba Compare August 29, 2019 23:12
@estebank
Copy link
Contributor Author

Should this be separated to new lint instead of overloading unreachable_patterns?

I'm explicitly not handling the "multiple holes caught by _" case because it has the potential of being extremely annoying. It likely belongs in clippy complaining about _ being bad style.

CC @varkor @oli-obk @Centril

@estebank estebank force-pushed the overlapping-patterns branch from cd6d7ba to 2731c02 Compare August 29, 2019 23:24
@varkor
Copy link
Member

varkor commented Aug 29, 2019

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).

src/librustc_mir/hair/pattern/_match.rs Outdated Show resolved Hide resolved
src/librustc_mir/hair/pattern/_match.rs Outdated Show resolved Hide resolved
src/librustc_mir/hair/pattern/check_match.rs Outdated Show resolved Hide resolved
@Centril Centril added I-nominated T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Aug 29, 2019
@rust-highfive

This comment has been minimized.

@estebank estebank force-pushed the overlapping-patterns branch from ea4ab95 to 4a8d83e Compare August 30, 2019 00:57
@joshtriplett
Copy link
Member

joshtriplett commented Sep 5, 2019

Conclusions from the lang team meeting:

  • We think there are legitimate use cases for some kinds of overlaps. For instance, matching a couple of specific letters and then matching a whole range that covers those letters as a fallback.
  • Thus, we think this would be prone to false positives.
  • We think some heuristics might help with that. For instance, overlapping ranges that don't completely overlap (0..10 and 5..15) seem more reasonable to warn about, rather than 5..10 and 0..20.

Because of that, we think this should be in clippy.

@scottmcm
Copy link
Member

scottmcm commented Sep 5, 2019

I feel strongly that this shouldn't be unreachable_patterns because the arm is reachable.

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".)

@estebank
Copy link
Contributor Author

estebank commented Sep 5, 2019

I could restrict this new lint to single element overlap (0..=10/10..=20) and disjointed partial overlaps (0..10/5..15) and ignore the common desired case (100..102/0..=255). That would cover the cases I was worried about to begin with. Is this reasonable? I don't mind dropping this and relying on clippy instead :)

@Centril
Copy link
Contributor

Centril commented Sep 5, 2019

I think going for the single element overlap (just for ranges) is something I'd be OK with in rustc.

@matthewjasper matthewjasper added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 9, 2019
@bors

This comment has been minimized.

@joshtriplett
Copy link
Member

joshtriplett commented Sep 12, 2019 via email

@hdhoang
Copy link
Contributor

hdhoang commented Sep 20, 2019

ping from triage @estebank, any update after the reviewers' comment?

@JohnCSimon
Copy link
Member

Pinging again from triage.
@estebank Can you please address the merge conflicts.
Thanks!

@JohnCSimon JohnCSimon added S-blocked-closed S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. and removed S-blocked-closed labels Oct 5, 2019
@JohnCSimon
Copy link
Member

Hello from triage:
@estebank -
This PR has sat idle for awhile, so I'm closing it as inactive,
Please reopen this when you have time to resolve the merge conflicts.

Thank you!

@JohnCSimon JohnCSimon closed this Oct 5, 2019
@estebank estebank reopened this Oct 7, 2019
@estebank estebank added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 8, 2019
Copy link
Contributor

@matthewjasper matthewjasper left a 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?

src/test/ui/issues/issue-13867.rs Outdated Show resolved Hide resolved
@Centril
Copy link
Contributor

Centril commented Oct 16, 2019

@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).

@estebank
Copy link
Contributor Author

@Centril done and done.

@matthewjasper
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Oct 19, 2019

📌 Commit 593cdcc has been approved by matthewjasper

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 19, 2019
Centril added a commit to Centril/rust that referenced this pull request Oct 19, 2019
…tthewjasper

Add check for overlapping ranges to unreachable patterns lint

Fix rust-lang#63987.
bors added a commit that referenced this pull request Oct 19, 2019
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
@bors bors merged commit 593cdcc into rust-lang:master Oct 19, 2019
bors added a commit that referenced this pull request Nov 12, 2019
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 ?
bors added a commit that referenced this pull request Nov 13, 2019
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 ?
bors added a commit that referenced this pull request Nov 15, 2019
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 ?
@estebank estebank deleted the overlapping-patterns branch November 9, 2023 05:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Lint against overlapping pattern ranges and pattern ranges with small holes caught by _
10 participants