"non-exhaustive patterns: _ not covered" message could be more helpful for bitwise matching

[indygreg]

I have code resembling the following:

pub fn parse_initial_byte(initial: u8) -> Result<InitialByte, &'static str> {
    match initial {
        0b000_00000...0b000_10111 => Ok(InitialByte::UIntInline(initial)),
        0b000_11000 => Ok(InitialByte::UInt8),
        0b000_11001 => Ok(InitialByte::UInt16),
        0b000_11010 => Ok(InitialByte::UInt32),
        0b000_11011 => Ok(InitialByte::UInt64),
        0b000_11100...0b000_11111 => Err("reserved major type 0 value"),
        0b001_00000...0b001_10111 => Ok(InitialByte::NegIntInline(-1 - (initial - 0x20) as i8)),
        0b001_11000 => Ok(InitialByte::NegInt8),
        0b001_11001 => Ok(InitialByte::NegInt16),
        0b001_11010 => Ok(InitialByte::NegInt32),
        0b001_11011 => Ok(InitialByte::NegInt64),
        0b001_11100...0b001_11111 => Err("reserved major type 1 value"),
        ...
    }

When compiling with Rust 1.31.0, I get the following output:

error[E0004]: non-exhaustive patterns: `_` not covered
  --> src/cbor.rs:70:11
   |
70 |     match initial {
   |           ^^^^^^^ pattern `_` not covered

error: aborting due to previous error

For more information about this error, try `rustc --explain E0004`.

My bitwise matching patterns are apparently non-exhaustive :/

The error message is useful in that it is telling me where the error is. But it isn't telling me exactly which value(s) aren't covered by the match. It would be extremely useful if the compiler could do that for me. As it stands, I'll likely have to add a match for _ and write a test that identifies which value(s) are hitting it. The amount of work is relatively small. But it would be ideal if the compiler gave me enough info to avoid this overhead.

[indygreg]

Talking with @withoutboats IRL, my understanding was slightly wrong here. Apparently the compiler can't figure out things and needs the _ match.

This wasn't at all intuitive to me: I thought the compiler was that smart and I was missing something in the match!

[nikic]

Exhaustive integer patterns recently got stabilized (on nightly). This will both enable the compiler to analyze this type of code and output a precise missing range, if one is missing.

The relevant tracking issue is #50907.

[estebank]

Fixed in nightly by the perviously mentioned PR:

error[E0004]: non-exhaustive patterns: `26u8..=247u8` and `249u8..=255u8` not covered
 --> src/lib.rs:2:11
  |
2 |     match initial {
  |           ^^^^^^^ patterns `26u8..=247u8` and `249u8..=255u8` not covered

[fintelia]

Now that the feature is stable, shouldn't this be closed?