Auto merge of #25778 - econoplas:master, r=pnkfelix

A regression was introduced by commit 7b1916d253 #25612.  Negative signed integer literals less than -9223372036854775808i64 were no longer properly reported as #[warn(overflowing_literals)].

Also adding missing test cases to test/compile-fail/lint-type-overflow.rs which could have detected the regression.

Further explanation:

The expression `(negative && v > max as u64 + 1)` relies on the fact that algebraically speaking `-min == max + 1` to avoid negation and removing the need for `min` completely.

If i128 or i256 are ever added, it should also work for these types without requiring a change to `min != i64::MIN &&` also simplifying maintenance.

r? @pnkfelix
This commit is contained in:
bors 2015-05-26 09:49:36 +00:00
commit 8a872943ff
2 changed files with 6 additions and 2 deletions

View File

@ -203,10 +203,12 @@ impl LintPass for TypeLimits {
} else {
t
};
let (min, max) = int_ty_range(int_type);
let (_, max) = int_ty_range(int_type);
let negative = self.negated_expr_id == e.id;
if (negative && min != i64::MIN && v > -min as u64) ||
// Detect literal value out of range [min, max] inclusive
// avoiding use of -min to prevent overflow/panic
if (negative && v > max as u64 + 1) ||
(!negative && v > max as u64) {
cx.span_lint(OVERFLOWING_LITERALS, e.span,
&*format!("literal out of range for {:?}", t));

View File

@ -52,6 +52,8 @@ fn main() {
let x = 9223372036854775808_i64; //~ error: literal out of range for i64
let x = -9223372036854775808_i64; // should be OK
let x = 18446744073709551615_i64; //~ error: literal out of range for i64
let x: i64 = -9223372036854775809; //~ error: literal out of range for i64
let x = -9223372036854775809_i64; //~ error: literal out of range for i64
let x = -3.40282348e+38_f32; //~ error: literal out of range for f32
let x = 3.40282348e+38_f32; //~ error: literal out of range for f32