Tracking issue for RFC 2438, "Deny the overflowing_literals lint for the 2018 edition" #54502

Activity

1. Centril

   added

   P-highHigh priorityHigh priority

   T-langRelevant to the language teamRelevant to the language team

   T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.

   on Sep 23, 2018
2. Centril commented on Sep 23, 2018

   

   Centril

   on Sep 23, 2018

   ContributorAuthor

   More actions

   Marked as P-high for T-compiler due to edition 2018.
3. Centril

   added

   B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.Blocker: Approved by a merged RFC but not yet implemented.

   C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFC

   on Sep 23, 2018
4. eddyb commented on Sep 23, 2018

   

   eddyb

   on Sep 23, 2018

   Contributor

   More actions

   @nikomatsakis Do we have a mechanism for per-edition default lint levels?
5. varkor commented on Sep 23, 2018

   

   varkor

   on Sep 23, 2018

   Contributor

   More actions

   Do we have a mechanism for per-edition default lint levels?

   Yes we do. We should just be able to replace:
   https://github.com/rust-lang/rust/blob/f0bae412e97db7ef26e24546bce5199c6a086152/src/librustc_lint/types.rs#L38-L42
   with:

   declare_lint! {
       OVERFLOWING_LITERALS,
       Warn,
       "literal out of range for its type",
       Edition::Edition2018 => Deny
   }
6. varkor

   added

   E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

   on Sep 23, 2018
7. ollie27 commented on Sep 23, 2018

   

   ollie27

   on Sep 23, 2018

   Contributor

   More actions

   Is there any reason it can't be made deny by default in the 2015 edition as well?
8. bors

   added a commit that references this issue on Sep 24, 2018

   Auto merge of #54507 - csmoe:deny_overflow, r=varkor

   ...

   e5c6575
9. bors

   closed this as completedin #54507on Sep 24, 2018
10. Centril

    reopened this on Sep 24, 2018
11. Centril commented on Sep 24, 2018

    

    Centril

    on Sep 24, 2018

    ContributorAuthor

    More actions

    Documentation is still todo
12. pnkfelix

    self-assigned this

    on Sep 27, 2018
13. 5 remaining items

    Load more
14. pnkfelix

    added

    A-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsArea: Documentation for any part of the project, including the compiler, standard library, and tools

    I-nominated

    and removed

    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.

    on Sep 28, 2018
15. pnkfelix

    removed their assignment

    on Sep 28, 2018
16. steveklabnik commented on Sep 30, 2018

    

    steveklabnik

    on Sep 30, 2018 via email

    Contributor

    More actions

    Lints are currently in the rustc book.

    …

    On Sep 28, 2018, at 8:59 AM, Felix S Klock II ***@***.***> wrote: The decision of what to do at this point is probably best laid in the hands of the docs team, not the compiler team. So I'm unassigning myself, reassigning the issue to the docs team, and tagging with I-nominated to try to promote its discussion amongst that team. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
17. Centril

    removed

    T-langRelevant to the language teamRelevant to the language team

    on Oct 4, 2018
18. ollie27 commented on Nov 2, 2018

    

    ollie27

    on Nov 2, 2018

    Contributor

    More actions

    Well I couldn't find any reason for it to only be deny by default on the 2018 edition so I've submitted #55632 to make it deny by default on all editions.
19. Centril

    removed

    I-nominated

    A-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsArea: Documentation for any part of the project, including the compiler, standard library, and tools

    P-highHigh priorityHigh priority

    on Feb 25, 2019
20. Centril commented on Feb 25, 2019

    

    Centril

    on Feb 25, 2019

    ContributorAuthor

    More actions

    Only rust-lang/edition-guide#146 remains now that #55632 is merged; closing therefore.
21. Centril

    closed this as completedon Feb 25, 2019
22. TheDan64 commented on Mar 13, 2019

    

    TheDan64

    on Mar 13, 2019

    Last edited by TheDan64

    Contributor

    More actions

    This broke some of my doc test code in inkwell while updating to 2018e which looked like this:
    assert_eq!(0b1110_0000i8 >> 1, 0b1111_0000i8);

    It was used as an example as to how sign extended bitshifting works.

    I don't really understand why this isn't valid. For example, looking at an even simpler example:
    let _x = 0b1110_0000i8; also won't compile:

    error: literal out of range for i8
     --> src/main.rs:2:14
      |
    2 |     let _x = 0b1110_0000i8;
      |              ^^^^^^^^^^^^^ help: consider using `u8` instead: `0b1110_0000u8`
      |
      = note: #[deny(overflowing_literals)] on by default
      = note: the literal `0b1110_0000i8` (decimal `224`) does not fit into an `i8` and will become `-32i8`

    However, it is my intent to specify the bit representation of an -32i8 (and it clearly has the i8 suffix), so how is this an overflow?

    👍React with 👍1Reacted by Anton Lazarev
23. oli-obk commented on Mar 13, 2019

    

    oli-obk

    on Mar 13, 2019

    Contributor

    More actions

    Rust's literals are not the bit representation of the final value. If they were, you'd get different result depending on whether you are on a big endian or a little endian machine (ok not for u8 and i8, but everything else).

    Instead the binary literals are the canonical binary representation of a positive integer, just like decimal literals are the canonical decimal representation of a positive integer. If you write 255_i8 that's the same thing as writing 0b1111_1111_i8, and 255 is not a valid i8.
24. TheDan64 commented on Mar 13, 2019

    

    TheDan64

    on Mar 13, 2019

    Contributor

    More actions

    I guess that makes sense, thanks for explaining. But it's certainly surprising behavior