Skip to content

ops::Range::end out of range (overflowing_literals) #47213

Closed

Description

@hellow554

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>>());
}

PlayGround

Activity

  1. hellow554 commented on Jan 5, 2018

    @hellow554
    ContributorAuthor

    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 :)

  2. leonardo-m commented on Jan 5, 2018

    @leonardo-m

    The solution is to use 0 ..= 255 to denote a closed interval. That syntax was invented to solve the problem you note.

  3. durka commented on Jan 5, 2018

    @durka
    Contributor

    This is the entire reason that inclusive ranges were added.

  4. durka commented on Jan 5, 2018

    @durka
    Contributor

    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.

  5. added
    A-diagnosticsArea: Messages for errors, warnings, and lints
    A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.
    on Jan 6, 2018
  6. added
    C-enhancementCategory: An issue proposing an enhancement or a PR with one.
    on Feb 12, 2018
  7. porglezomp commented on May 11, 2018

    @porglezomp
    Contributor

    I'd like to try working on this issue.

  8. porglezomp commented on May 11, 2018

    @porglezomp
    Contributor

    How does this look for a possible message?

    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
    
  9. leonardo-m commented on May 12, 2018

    @leonardo-m

    That message seems nice.

  10. hellow554 commented on May 12, 2018

    @hellow554
    ContributorAuthor

    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

  11. porglezomp commented on May 12, 2018

    @porglezomp
    Contributor

    You're right, that should say "inclusive." I should also handle ..256u8 -> ..=255u8, even though that's probably a much less common case.

  12. hellow554 commented on May 23, 2018

    @hellow554
    ContributorAuthor

    @porglezomp Any progress? Did you open a PR?

  13. porglezomp commented on May 24, 2018

    @porglezomp
    Contributor

    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.

  14. added 3 commits that reference this issue on May 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.C-enhancementCategory: An issue proposing an enhancement or a PR with one.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions