Integral literals larger than i64::MAX are not detected as overflow #14269
Labels
A-lints
Area: Lints (warnings about flaws in source code) such as unused_mut.
Comments
|
Duplicate of #2252 ? |
|
@hirschenberger #2252 appears to be a specific issue about float literals. |
|
Right, but there #4220 was mentioned, which is closed but handeled a similar problem for ints. |
|
@hirschenberger Look closer. #4220 was fixed by the |
|
You're right, sorry. |
|
I have patch which solves this issue, but a runtime test is failing now which tests https://github.com/rust-lang/rust/blob/master/src/test/run-pass/big-literals.rs#L18-L19 whereas the |
hirschenberger
added a commit
to hirschenberger/rust
that referenced
this issue
Jul 24, 2014
The `type_overflow` lint, doesn't catch the overflow for `i64` because the overflow happens earlier in the parse phase when the `u64` as biggest possible int gets casted to `i64` , without checking the for overflows. We can't lint in the parse phase, so a refactoring of the `LitInt` type was necessary. The types `LitInt`, `LitUint` and `LitIntUnsuffixed` where merged to one type `LitInt` which stores it's value as `u64`. An additional parameter was added which indicate the signedness of the type and the sign of the value.
hirschenberger
added a commit
to hirschenberger/rust
that referenced
this issue
Aug 5, 2014
The `type_overflow` lint, doesn't catch the overflow for `i64` because the overflow happens earlier in the parse phase when the `u64` as biggest possible int gets casted to `i64` , without checking the for overflows. We can't lint in the parse phase, so a refactoring of the `LitInt` type was necessary. The types `LitInt`, `LitUint` and `LitIntUnsuffixed` where merged to one type `LitInt` which stores it's value as `u64`. An additional parameter was added which indicate the signedness of the type and the sign of the value.
bors
added a commit
that referenced
this issue
Aug 5, 2014
Fixes missing overflow lint for i64 #14269 The `type_overflow` lint, doesn't catch the overflow for `i64` because the overflow happens earlier in the parse phase when the `u64` as biggest possible int gets casted to `i64` , without checking the for overflows. We can't lint in the parse phase, so we emit a compiler error, as we do for overflowing `u64` Perhaps a consistent behaviour would be to emit a parse error for *all* overflowing integer types. See #14269
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
type_overflowlint does not catch integral literals larger thani64::MAX. I have to assume the problem is the overflow happens when generating the AST, and the lint operates on the AST, so it can't tell that it overflowed.Example:
It does manage to catch
18446744073709551616, which is a parse error ("int literal is too large"). This isu64::MAX + 1, so the parser can definitively tell it's too large even though it doesn't know which integral type is being used.The text was updated successfully, but these errors were encountered: