Clarified error note for usize range matching

[helldawg]

Fixes #146476

This is (I think) partly incorrect, but it gets the point across a little better and stays short.

r? @workingjubilee
@rustbot label A-diagnostics A-exhaustiveness-checking A-patterns

[rustbot]

Some changes occurred in match checking

cc @Nadrieril

[rustbot]

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

[workingjubilee]

Need to also fix the tests which may just require an ./x.py test ./tests/ui --bless

[fmease]

Suggested change

	"The minimum and maximum values of `{ty}` are not directly accessible, so half-open \
	"the minimum and maximum values of `{ty}` are not directly accessible, so half-open \

https://rustc-dev-guide.rust-lang.org/diagnostics.html#diagnostic-output-style-guide

[helldawg]

Not really sure how to fix this failing check. It's being compared to the old one, even with the updated stderr. Seems like it's checking for stdout?

[cyrgani]

You also need to update the error annotations within the test files themselves such as "NOTE usize does not have a fixed maximum value". (https://rustc-dev-guide.rust-lang.org/tests/ui.html#error-annotations)

[helldawg]

You also need to update the error annotations within the test files themselves such as "NOTE usize does not have a fixed maximum value". (https://rustc-dev-guide.rust-lang.org/tests/ui.html#error-annotations)

Gotcha, thank you.

[workingjubilee]

Hmm. I'm not sure what "accessible" is intended to mean here, as in a sense of "the path to the item", it sure is accessible.

[helldawg]

Hmm. I'm not sure what "accessible" is intended to mean here, as in a sense of "the path to the item", it sure is accessible.

I think "accessible" means I need to access more sleep, because it looks like I was not comprehending anything I read.

Thinking of changing it to:
"usize::MAX is not treated as exhaustive, so half-open ranges are necessary to match exhaustively"
and
"isize::MIN and isize::MAX are not treated as exhaustive, so half-open ranges are necessary to match exhaustively"

Or "considered" instead of "treated as"

[workingjubilee]

Mm. Maybe it would be good to think about this example:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=07824b8c993d26743b4a371df42b106b

Notice how usize::MAX is... well, no longer "actually" usize::MAX.

usize::MAX is a library constant and remains so which also means shadowing it is fair game. It's a bit of a case of "I love it when I can implement the same things as the standard library does! ...No, wait, not like that 😭"

So usize patterns do not consider any particular constant as forming the upper bound of the type. This also handles the case, as mentioned in the issue, of

const USIZE_MAX: usize = usize::MAX;

Which arguably should be treated as the exhaustive upper bound if we treat usize::MAX also, but at what cost of compiler complexity and code correctness? Should it differ if one copies the literal there?

[workingjubilee]

You don't need to present an elaborate justification about compiler implementation, mind, indeed I expect most are not interested in that, I'm just noting some things.

[helldawg]

I considered elaborating on why this doesn't work the way it intuitively should, but decided that it wouldn't add all that much value in the end. The rationale being that knowing about the exact compiler quirk won't make it compile any better than the suggested fix (which might have some room for improvement here?) or, y'know, making work as it theoretically should on the compiler level.