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

non-exhaustive patterns false positive #73919

Closed
leonardo-m opened this issue Jul 1, 2020 · 7 comments · Fixed by #73937
Closed

non-exhaustive patterns false positive #73919

leonardo-m opened this issue Jul 1, 2020 · 7 comments · Fixed by #73937
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@leonardo-m
Copy link

fn foo(x: usize) -> u32 {
    match x {
        0 ..= usize::MAX => 0
    }
}
fn main() {}

Gives:

error[E0004]: non-exhaustive patterns: `_` not covered
 --> ...\test.rs:2:11
  |
2 |     match x {
  |           ^ pattern `_` not covered
  |
  = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
  = note: the matched value is of type `usize`
@leonardo-m leonardo-m added the C-bug Category: This is a bug. label Jul 1, 2020
@jonas-schievink
Copy link
Contributor

Fairly sure this is intentional for usize

@jonas-schievink jonas-schievink added A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns and removed C-bug Category: This is a bug. labels Jul 1, 2020
@JohnTitor JohnTitor added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jul 1, 2020
@leonardo-m
Copy link
Author

From the pull 73937 I've seen a part that I didn't see/remember:

An unstable feature precise_pointer_size_matching will be added to permit matching exactly on pointer-size integer types.

So you're right, this isn't a new bug, it's a known unfinished part. I hope to see that precise_pointer_size_matching implemented.

@varkor
Copy link
Member

varkor commented Jul 3, 2020

I hope to see that precise_pointer_size_matching implemented.

It already exists.

@leonardo-m
Copy link
Author

I see, then what do I have to hope to see? :-)

@varkor
Copy link
Member

varkor commented Jul 3, 2020

I'm not sure the feature is ever going to be stabilised, because there are concerns that this isn't a desirable feature. But hopefully the diagnostics will at least be improved in #73937.

@leonardo-m
Copy link
Author

Do you have a link to such concerns? (Or are you willing to summarize them?)
(I value your work on the compiler a lot varkor :-) )

@varkor
Copy link
Member

varkor commented Jul 4, 2020

I think the relevant concerns arose in the RFC thread (from this comment up). The overview is that we ought not to make assumptions about pointer sizes on the target platform, because they're not guaranteed to be fixed, so this could cause compatibility issues.

@bors bors closed this as completed in a1ac4d6 Jul 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants