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

Specific error message when trying to exhaustively match on pointer types #65712

Closed
SergioBenitez opened this issue Oct 22, 2019 · 5 comments
Closed
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` C-enhancement Category: An issue proposing an enhancement or a PR with one. D-confusing Diagnostics: Confusing error or lint that should be reworked. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@SergioBenitez
Copy link
Contributor

SergioBenitez commented Oct 22, 2019

As the title suggests, exhaustive pattern checking for usize and isize fails when checks for similar patterns for {i,u}{n} succeed. Consider the following program (playground link):

// Okay.
fn g(len: u8) {
    match len {
        0 => { }
        1 => { }
        2 => { }
        3 ..= std::u8::MAX => { }
    }
}

// Fails.
fn f(len: usize) {
    match len {
        0 => {},
        1 => {},
        2 => {},
        3 ..= std::usize::MAX => {},
    }
}

// Okay.
fn j(len: i32) {
    match len {
        std::i32::MIN ..= -1 => {},
        0 => { }
        1 => { }
        2 => { }
        3 ..= std::i32::MAX => { }
    }
}

// Fails.
fn h(len: isize) {
    match len {
        std::isize::MIN ..= -1 => {},
        0 => { }
        1 => { }
        2 => { }
        3 ..= std::isize::MAX => { }
    }
}

While checking succeeds for g (u8) and j (i32), it fails for f (usize) and h (isize).

cc @varkor


This is intentional (exhaustive matching on pointers is tracked at #56354), but where we would exhaustively match, then we could suggest using #![feature(precise_pointer_size_matching)] and explain why the pattern wasn't exhaustively matched.

@varkor
Copy link
Member

varkor commented Oct 23, 2019

Exhaustive pattern matching is disabled by default for usize and isize because the width differs depending on the platform. You can enable it using #![feature(precise_pointer_size_matching)]. There's a tracking issue at #56354.

@varkor varkor closed this as completed Oct 23, 2019
@SergioBenitez
Copy link
Contributor Author

@varkor If that's the case, the error message should allude to this.

@varkor
Copy link
Member

varkor commented Oct 23, 2019

That's a good point — we could emit better diagnostics here. Let's repurpose this issue for that.

@varkor varkor reopened this Oct 23, 2019
@varkor varkor changed the title Exhaustive pattern checking for 'usize', 'isize' fails Specific error message when trying to exhaustively match on pointer types Oct 23, 2019
@varkor varkor added A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` D-confusing Diagnostics: Confusing error or lint that should be reworked. labels Oct 23, 2019
@estebank estebank added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Feb 1, 2020
@crlf0710 crlf0710 added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jun 11, 2020
@Nadrieril
Copy link
Member

The error is now:

error[E0004]: non-exhaustive patterns: `_` not covered
 --> src/main.rs:2:11
  |
2 |     match len {
  |           ^^^ 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`
  = note: `usize` does not have a fixed maximum value, so a wildcard `_` is necessary to match exhaustively

So we can close this

@varkor
Copy link
Member

varkor commented Nov 19, 2020

And there's a test for it already, perfect.

error[E0004]: non-exhaustive patterns: `_` not covered
--> $DIR/non-exhaustive-pattern-pointer-size-int.rs:4:11
|
LL | match 0usize {
| ^^^^^^ 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`
= note: `usize` does not have a fixed maximum value, so a wildcard `_` is necessary to match exhaustively
= help: add `#![feature(precise_pointer_size_matching)]` to the crate attributes to enable precise `usize` matching

Thanks!

@varkor varkor closed this as completed Nov 19, 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-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` C-enhancement Category: An issue proposing an enhancement or a PR with one. D-confusing Diagnostics: Confusing error or lint that should be reworked. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants