Open Alcaro opened 1 year ago
@rustbot claim
@rustbot release-assignment
2147483649-1
is equal to i32::MIN
, which is then negated causing overflow, no?
So the problem here is that this arithmetic operation will overflow
is useless if and only if the literal out of range
shows up. Remember that these lints can be toggled independently.
This code:
#[allow(overflowing_literals)]
let _ = -(2147483649-1); // note: 2147483649 == -2147483647_i32
errors with the expected and helpful lint
error: this arithmetic operation will overflow
--> src/main.rs:3:13
|
3 | let _ = -(2147483649-1); // note: 2147483649 == -2147483647_i32
| ^^^^^^^^^^^^^^^ attempt to negate `i32::MIN`, which would overflow
|
= note: `#[deny(arithmetic_overflow)]` on by default
This might be helped by emitting "literal out of range" before other integer related lints, but I am not sure if that's possible or useful in the general case.
@rustbot claim
It looks the literal out of range
doesn't always trigger arithmetic overflow
. For example, 128_i8 + 1
only emits literal out of range
.
When a literal is out of range, the wrapped value of literal will be used in the check of arithmetic overflow
.
So I think the diagnostic message in this issue is not a problem.
which means the expression doesn't have a value, and issuing diagnostics about a non-value is just misleading.
This is not correct, out of range literals just wrap around, in this case to -1. The diagnostic is correct, it's just a bit confusing. The overflowing literals lint should probably mention what actual value will be used.
Code
Current output
Desired output
Rationale and extra context
The paren's contents are not i32::MIN; it's denied by overflowing_literals, which means the expression doesn't have a value, and issuing diagnostics about a non-value is just misleading.
Especially considering it's above the real error; the top error is usually the most important, but not here.
Other cases
No response
Anything else?
No response