Repository navigation
Missing some warnings about "literal out of range for its type" #14165
Description
The places I'd expect to get warnings are indicated by the comments in this example:
fn main() {
let a: u8 = 1000;
let b = 1000u8;
let c = 1000 as u8; // NO WARNING !!!
let one: u8 = 1;
let d = (one * 1000) as u32;
let e = (one * -1) as u32; // NO WARNING !!!
let f = (one * -255) as u32; // NO WARNING !!!
let g = (one * -256) as u32;
println!("{}, {}, {}, {}, {}, {}, {}", a, b, c, d, e, f, g);
}
Here's the compiler output:
warning: literal out of range for its type, #[warn(type_overflow)] on by default
let a: u8 = 1000;
^~~~
warning: literal out of range for its type, #[warn(type_overflow)] on by default
let b = 1000u8;
^~~~~~
warning: literal out of range for its type, #[warn(type_overflow)] on by default
let d = (one * 1000) as u32;
^~~~
warning: literal out of range for its type, #[warn(type_overflow)] on by default
let g = (one * -256) as u32;
^~~
And here's the program output:
232, 232, 232, 232, 255, 1, 0
Activity
lilyball commentedon May 18, 2014
-1u8produces anunsigned_negatewarning, not atype_overflowwarning. Consequently,(one * -1)is correct in not producing atype_overflowwarning.This same logic applies to
(one * -255)as well.255is in range for its type, so it doesn't get atype_overflowwarning.It is arguable as to whether these cases should produce an
unsigned_negatewarning.lilyball commentedon May 20, 2014
Saying
### as u8should never produce a warning. That's an explicit cast, which means you're opting in to overflow behavior.Which is to say,
-12uis likely to be unintentional, and the warning calls it out.-12 as uintis very much intentional. And in fact, if you get anunsigned_negatewarning, the easiest way to fix it if it was intentional is to convert it to anascast.Same thing with
1000 as u8. That right there is explicitly asking for the results of casting1000to au8type. The warning has a too-high probability of being a false positive.lilyball commentedon May 21, 2014
let x: u8 = -1feels more like an oversight to me, but I suspect it's actually a deliberate omission because it ends up being the exact same thing as1u8 * -1. In both cases, the-1is an unsuffixed integer literal, which is subsequently constraint to theu8type.Of course, I can only speculate. I didn't implement the lint. But my feeling is that
-1u8is obviously weird and a lint on it is wholly unsurprising, but1u8 * -1is not so obviously weird, and flagging it with a lint may be more surprising (and have more false positives).hirschenberger commentedon May 23, 2014
Hi, I wrote the lint for the unsigned negation and wanted to catch the obvious cases negating unsigned literals. A related issue to the case @tommit mentioned is #5477.
The question is where we should draw the line between intentional and unintentional behaviour being helpful without annoying users?
huonw commentedon Jan 13, 2015
Duplicate of #5477.
Auto merge of rust-lang#14165 - Veykril:completion-item, r=Veykril
extend `obfuscated_if_else` to support `{then(), then_some()}.unwrap_…