You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ops::Range::end out of range (overflowing_literals) #47213
I would expect that the the following prints would lead to the same result, instead rust complains about 256 being out of range for u8, which is correct, but because end is exclusive, it should't complain.
#![feature(inclusive_range_syntax)]
fn main() {
let range_a = 0..256;
let range_b = 0..=255;
println!("{:?}", range_a.collect::<Vec<u8>>());
println!("{:?}", range_b.collect::<Vec<u8>>());
}
Okay, after thinking about this issue and talking with somebody this is very, very difficult to solve. Range uses the underlying type (in this case it is an u8) and so it complains about being out of range (256 does not fit into a u8, period!)
In this case (aloso for u16, i16, u32, ...) it should work, yes, but range is defined for a type that implements PartialOrd and not only numeric literals which is indeed a problem.
The question, is this anyhow solveable?
If somebody stumbles across this, I'd like to hear his/her comment, but would also accept a comment closed #Notabug :)
Actually -- perhaps keep this open as a diagnostics issue? Is it possible for overflowing_literals to have a note recommending an inclusive range? Sorry for my dismissive tone in the previous comment.
warning: literal out of range for u8
--> $DIR/suggestions.rs:61:23
|
LL | for _ in 0u8..256 { }
| -----^^^
| |
| help: use a closed range: `0u8..=255`
|
= note: #[warn(overflowing_literals)] on by default
Closed or inclusive range? The feature was named inclusive, that's why I'm asking.
Also, can you please verify, that the note will not appear with 257? 😅 Would be a classic that I would forget to Check
I haven't made much progress unfortunately, I got distracted by other things and don't know enough about the compiler internals to work very fast. If someone else wants to pick it up that's fine by me; if not, I'll get it done eventually.
Activity
hellow554 commentedon Jan 5, 2018
Okay, after thinking about this issue and talking with somebody this is very, very difficult to solve.
Range uses the underlying type (in this case it is an u8) and so it complains about being out of range (256 does not fit into a u8, period!)
In this case (aloso for u16, i16, u32, ...) it should work, yes, but range is defined for a type that implements PartialOrd and not only numeric literals which is indeed a problem.
The question, is this anyhow solveable?
If somebody stumbles across this, I'd like to hear his/her comment, but would also accept a comment closed #Notabug :)
leonardo-m commentedon Jan 5, 2018
The solution is to use 0 ..= 255 to denote a closed interval. That syntax was invented to solve the problem you note.
durka commentedon Jan 5, 2018
This is the entire reason that inclusive ranges were added.
durka commentedon Jan 5, 2018
Actually -- perhaps keep this open as a diagnostics issue? Is it possible for
overflowing_literalsto have a note recommending an inclusive range? Sorry for my dismissive tone in the previous comment.porglezomp commentedon May 11, 2018
I'd like to try working on this issue.
porglezomp commentedon May 11, 2018
How does this look for a possible message?
leonardo-m commentedon May 12, 2018
That message seems nice.
hellow554 commentedon May 12, 2018
Closed or inclusive range? The feature was named inclusive, that's why I'm asking.
Also, can you please verify, that the note will not appear with 257? 😅 Would be a classic that I would forget to Check
porglezomp commentedon May 12, 2018
You're right, that should say "inclusive." I should also handle
..256u8->..=255u8, even though that's probably a much less common case.hellow554 commentedon May 23, 2018
@porglezomp Any progress? Did you open a PR?
porglezomp commentedon May 24, 2018
I haven't made much progress unfortunately, I got distracted by other things and don't know enough about the compiler internals to work very fast. If someone else wants to pick it up that's fine by me; if not, I'll get it done eventually.
Rollup merge of rust-lang#60330 - varkor:range-endpoint-overflow-lint…
Rollup merge of rust-lang#60330 - varkor:range-endpoint-overflow-lint…
Rollup merge of rust-lang#60330 - varkor:range-endpoint-overflow-lint…