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

Fix overlap detection of usize/isize range patterns #79523

Merged
merged 2 commits into from
Nov 29, 2020

Conversation

Nadrieril
Copy link
Member

@Nadrieril Nadrieril commented Nov 28, 2020

usize and isize are a bit of a special case in the match usefulness algorithm, because the range of values they contain depends on the platform. Specifically, we don't want 0..usize::MAX to count as an exhaustive match (see also precise_pointer_size_matching). The way this was initially implemented is by treating those ranges like float ranges, i.e. with limited cleverness. This means we didn't catch the following as unreachable:

match 0usize {
    0..10 => {},
    10..20 => {},
    5..15 => {}, // oops, should be detected as unreachable
    _ => {},
}

This PRs fixes this oversight. Now the only difference between usize and u64 range patterns is in what ranges count as exhaustive.

r? @varkor
@rustbot label +A-exhaustiveness-checking

We prefer to grab `ty` and `span` from `pcx`. This makes it consistent
with other constructors.
@rustbot rustbot added the A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns label Nov 28, 2020
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 28, 2020
@Nadrieril
Copy link
Member Author

I also measured a perf improvement, so I'd like a perf run to confirm it.

@jonas-schievink
Copy link
Contributor

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Nov 28, 2020

⌛ Trying commit bdd2bdb with merge 0c01a2145a2a5a57d0c24fa0661e1ca155aa202e...

@bors
Copy link
Contributor

bors commented Nov 29, 2020

☀️ Try build successful - checks-actions
Build commit: 0c01a2145a2a5a57d0c24fa0661e1ca155aa202e (0c01a2145a2a5a57d0c24fa0661e1ca155aa202e)

@rust-timer
Copy link
Collaborator

Queued 0c01a2145a2a5a57d0c24fa0661e1ca155aa202e with parent e37f25a, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (0c01a2145a2a5a57d0c24fa0661e1ca155aa202e): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-perf

@Nadrieril
Copy link
Member Author

I'm surprised by the perf gain on match-stress-enum, particularly since it was caused by the first commit. My only guess it that split got simple enough to be inlined. I'm worried I'll lose that gain if I touch anything ^^

@varkor
Copy link
Member

varkor commented Nov 29, 2020

Thanks!

@bors r+ rollup=never

@bors
Copy link
Contributor

bors commented Nov 29, 2020

📌 Commit bdd2bdb has been approved by varkor

@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 Nov 29, 2020
@bors
Copy link
Contributor

bors commented Nov 29, 2020

⌛ Testing commit bdd2bdb with merge b776d1c...

@bors
Copy link
Contributor

bors commented Nov 29, 2020

☀️ Test successful - checks-actions
Approved by: varkor
Pushing b776d1c to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 29, 2020
@bors bors merged commit b776d1c into rust-lang:master Nov 29, 2020
@rustbot rustbot added this to the 1.50.0 milestone Nov 29, 2020
@Nadrieril Nadrieril deleted the fix-usize-ranges branch November 29, 2020 21:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants