Matching on `usize` requires half-open range

[mkeeter]

usize ranges in match statements are surprising:

fn test(i: usize) {
    match i {
        0..=usize::MAX => todo!(),
    }
}

I expected this to compile; instead, rustc returns an error:

error[E0004]: non-exhaustive patterns: `usize::MAX..` not covered
 --> src/lib.rs:2:11
  |
2 |     match i {
  |           ^ pattern `usize::MAX..` not covered
  |
  = note: the matched value is of type `usize`
  = note: `usize` does not have a fixed maximum value, so half-open ranges are necessary to match exhaustively
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
  |
3 ~         0..=usize::MAX => todo!(),
4 ~         usize::MAX.. => todo!(),
  |

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

This is obviously a known edge case, given the custom error message (which is great!), but it's still a weird paper cut. It's especially weird to declare "usize does not have a fixed maximum value" when usize::MAX is right there!

Doing a little digging, it looks like it dates back to at least #118598

Meta

rustc --version --verbose:

rustc 1.89.0 (29483883e 2025-08-04)
binary: rustc
commit-hash: 29483883eed69d5fb4db01964cdf2af4d86e9cb2
commit-date: 2025-08-04
host: aarch64-apple-darwin
release: 1.89.0
LLVM version: 20.1.7

[workingjubilee]

This is an interesting quirk of the way the type is defined. Technically, the compiler has no special knowledge of the usize::MAX constant: it just is a value. The fact that it will, across all compilation sessions, mystically always be the largest value of usize (well, unless the stdlib is implemented incorrectly) is a mystery to the compiler.

[fmease]

Doing a little digging, it looks like it dates back to at least #118598

I mean the PR description basically explains why it is the way it is and I don't see how we would 'fix' this in a principled and performant manner.

Of course, we could slap some #[lang] or #[rustc_*] attr on the MAX const in the stdlib but is that really principled? Unless we somehow track this metadata in the const value itself (similar to initializedness and provenance I guess; probably extremely expensive to maintain), this wouldn't be "closed under" normalization (evaluation). Consider MY_MAX set to usize::MAX - 1 + 1, (usize::MAX,).0, etc.

And if it "doesn't work with" normalization, it would just be a super weird special case that's equivalent to just using a half-open range.

In any case, there might be merit in clarifying that diagnostic note even further.

[fmease]

It is unfortunate but not world shattering imo. In my mind, it compares to constructs like loop {} chosen over while KNOWN_TO_EVAL_TO_TRUE {} as a more restricted version of another construct that allows for more static guarantees. Does that make sense?

[workingjubilee]

seems like a clear diagnostic bug, tbh, even if it is mostly going to be about choosing different words.