use MIN/MAX constant names in integer pattern coverage messages
#57073
Conversation
While many programmers may intuitively appreciate the significance of magic numbers like −2147483648, Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names. The `max_as_i128`, &c. methods strewn in libsyntax are a bit unsightly, but I fear this is really the most natural way to solve the problem. Resolves rust-lang#56393.
rust-highfive
added
the
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Using |
| @@ -10,11 +10,11 @@ note: lint level defined here | |||
| LL | #![deny(unreachable_patterns)] | |||
| | ^^^^^^^^^^^^^^^^^^^^ | |||
|
|
|||
| error[E0004]: non-exhaustive patterns: `128u8..=255u8` not covered | |||
| error[E0004]: non-exhaustive patterns: `128u8..=::std::u8::MAX` not covered | |||
There was a problem hiding this comment.
There's quite a lot of syntax in here (..=::) making this a bit hard to read. Could we get away with not including the ::std:: prefix and just using 128u..=u8::MAX? I realize this may not work if the user decides to directly copy&paste this to create an extra range, but it would reduce the noise in the message.
There was a problem hiding this comment.
I agree that it's quite noisy, but considering that the compiler doesn't currently suggest importing std::u8 if u8::MAX is not found, it could be confusing that it's not possible to directly copy and paste. Maybe we could start with this more verbose version and then cut it down after implementing a suggestion for importing std::u8.
I think we should detect whether |
| @@ -1458,6 +1458,29 @@ impl IntTy { | |||
| IntTy::I128 => 128, | |||
| }) | |||
| } | |||
|
|
|||
| pub fn min_as_i128(&self) -> i128 { | |||
There was a problem hiding this comment.
You can avoid enumerating the integer types using the bit manipulations that are already used for range pattern matching, e.g.:
https://github.com/rust-lang/rust/blob/96295ad2957a389c7b108b769532ecd7cada9918/src/librustc_mir/hair/pattern/_match.rs#L686-L689
There was a problem hiding this comment.
Although these should be refactored as part of #49937 anyway, it probably makes more sense to have these in mir/mod.rs if that's the only place they're used.
|
|
||
| pub fn min_as_i128(&self) -> i128 { | ||
| match *self { | ||
| IntTy::Isize => ::std::isize::MIN as i128, |
There was a problem hiding this comment.
This is going to use the host isize size, rather than the target size. (Using the snippet above will address that.)
| @@ -1496,6 +1519,17 @@ impl UintTy { | |||
| UintTy::U128 => 128, | |||
| }) | |||
| } | |||
|
|
|||
| pub fn max_as_u128(&self) -> u128 { | |||
There was a problem hiding this comment.
| Uint(ui) => return write!(f, "{:?}{}", bits, ui), | ||
| Uint(ui) => { | ||
| return match bits { | ||
| // writing 0 as uX::MIN wouldn't clarify |
There was a problem hiding this comment.
| // writing 0 as uX::MIN wouldn't clarify | |
| // Writing `0` as `uX::MIN` wouldn't make the value any clearer, | |
| // so we only special-case the maximum value. |
| return write!(f, "{:?}{}", ((bits as i128) << shift) >> shift, i); | ||
| let n = ((bits as i128) << shift) >> shift; | ||
| return match n { | ||
| m if m == i.min_as_i128() => write!(f, "::std::{}::MIN", i), |
There was a problem hiding this comment.
| m if m == i.min_as_i128() => write!(f, "::std::{}::MIN", i), | |
| _ if n == i.min_as_i128() => write!(f, "::std::{}::MIN", i), |
This is just stylistic, but I think it's clearer what value you're testing if you don't mind n to a different variable name (here and above).
varkor
added
S-waiting-on-author
|
☔ The latest upstream changes (presumably #57108) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Triage; @zackmdavis Hello, have you been able to get back to this PR? |
|
@Aaronepower estimate Sunday the 13th |
Actually not, but this is in my awareness/TODO list |
TimNN
added
A-allocators
|
ping fromt triage @zackmdavis: What is the status of this PR? |
|
Really sorry, my dayjob and non-rustc life has been crazy lately. I'll close this for now to keep the PR queue clean, but looking forward to having hacking time at the all-hands next week?! |
|
Ugh, there's this really annoying thing where the shift in |
…_cognition, r=varkor pretty-pretty extremal constants! (A resurrection of the defunct #57073.) While many programmers may intuitively appreciate the significance of "magic numbers" like −2147483648, Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names (even noisy fully-qualified-paths thereof). The bit-manipulation methods mirror those in `librustc_mir::hair::pattern::_match::all_constructors`; thanks to the immortal Varkor for guidance. Resolves #56393. r? @varkor
While many programmers may intuitively appreciate the significance of magic numbers like −2147483648, Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names.
The
max_as_i128, &c. methods strewn in libsyntax are a bit unsightly, but I fear this is really the most natural way to solve the problem.Question: is it OK to have chosen
::std::isize::MIN(&c.) as the symbolic names, or willno_stdcrate authors be mad??Resolves #56393.
r? @varkor