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 match for masked integer #30578

Closed
crawford opened this Issue Dec 27, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@crawford
Copy link

crawford commented Dec 27, 2015

I have the following program which fails to compile:

fn main() {
    println!("{}", match 123 & 0x01 {
        0x00 => "Hello",
        0x01 => "World",
    });
}

with the following error:

foo.rs:2:20: 5:6 error: non-exhaustive patterns: `_` not covered [E0004]
foo.rs:2     println!("{}", match 123 & 0x01 {
foo.rs:3         0x00 => "Hello",
foo.rs:4         0x01 => "World",
foo.rs:5     });
<std macros>:2:25: 2:56 note: in this expansion of format_args!
<std macros>:3:1: 3:54 note: in this expansion of print! (defined in <std macros>)
foo.rs:2:5: 5:8 note: in this expansion of println! (defined in <std macros>)
foo.rs:2:20: 5:6 help: run `rustc --explain E0004` to see a detailed explanation
error: aborting due to previous error

It would be really nice if the compiler could recognize that foo & 0x01 can only result in 0x00 or 0x01, making the match exhaustive.

This looks related to #12483.

@arielb1

This comment has been minimized.

Copy link
Contributor

arielb1 commented Dec 27, 2015

Exhaustiveness analysis cares only about types. The type of your masked integer is still i32.

@arielb1 arielb1 closed this Dec 27, 2015

@crawford

This comment has been minimized.

Copy link
Author

crawford commented Dec 27, 2015

Yes, but i32 is guaranteed to be only one of two values in this case. Does it make sense for the exhaustiveness analysis to look at more than just the types? Or does it make sense for 123 & 0x01 to result in an internal subtype of i32 (an i1 in this case)?

@arielb1

This comment has been minimized.

Copy link
Contributor

arielb1 commented Dec 27, 2015

@crawford

No and there is no plan for making Rust's analyses to be based on runtime properties other than types.

@arielb1

This comment has been minimized.

Copy link
Contributor

arielb1 commented Dec 27, 2015

Of course, if we ever implement dependent types or something, we would integrate it with the exhaustiveness checker, but until then, we won't be working in this direction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment