Special case overflowing literal lints to warn about -iX::MIN

[AaronKutch]

I just found several issues where people forget that -i32::MAX != i32::MIN, i32::MAX == 7fffffff while i32::MIN == -0x80000000. People see that -0x80000000 works and then mistakenly try to use +0x80000000 which doesn't work because i32 can't represent it. What we should actually do is detect when people try to type out 0x80000000i32 or 0x80i8, etc, and have a lint that warns about this problem. I'm thinking the lint should suggest casting to the unsigned type and back, because the user is probably trying to do bit manipulation which has subtleties with signed integers.

#53628, #99195, #108269

[gurry]

I'm thinking the lint should suggest casting to the unsigned type and back, because the user is probably trying to do bit manipulation which has subtleties with signed integers.

I think that is already roughly what the compiler suggests.

For example, this code:

#[allow(unused_variables)]
fn main() {
    let a = 5;
    let b = a ^ 0x80000000i32; 
}

results in the following diagnostic:

error: literal out of range for `i32`
 --> src/main.rs:4:17
  |
4 |     let b = a ^ 0x80000000i32; 
  |                 ^^^^^^^^^^^^^
  |
  = note: the literal `0x80000000i32` (decimal `2147483648`) does not fit into the type `i32` and will become `-2147483648i32`
  = note: `#[deny(overflowing_literals)]` on by default
help: consider using the type `u32` instead
  |
4 |     let b = a ^ 0x80000000u32; 
  |                 ~~~~~~~~~~~~~
help: to use as a negative number (decimal `-2147483648`), consider using the type `u32` for the literal and cast it to `i32`
  |
4 |     let b = a ^ 0x80000000u32 as i32; 
  |                 ~~~~~~~~~~~~~~~~~~~~

Maybe you want an additional note there about the pitfalls of using "edge" values like 0x80000000i32 because they are easily and often misconstrued as positive? Perhaps this note can also show an additional suggestion for -0x80000000i32 apart from the cast suggestion already shown.

[gurry]

I'm thinking the lint should suggest casting to the unsigned type and back, because the user is probably trying to do bit manipulation which has subtleties with signed integers.

I think that is already roughly what the compiler suggests.

The compiler didn't actually do that when the issue was filed. The help in question was added later in PR #111212.

So given that we have these suggestions now, would it make sense to close this issue?

[AaronKutch]

The first new note solves half the issue cases I think. There are cases where people might not understand the asymmetry between MIN and MAX, it is not immediately obvious why removing an unary negative causes these errors unless you know about the edge case. I think one extra note should be added just for the iX::MIN case that says with hexadecimal, "note: iX::MIN == -0x80..., but iX::MAX == 0x7ff..., meaning that positive 0x80... is not representable as an iX." with the 'X' and '...' properly filled in.

[gurry]

Makes sense