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

[Centril]

This is a tracking issue for the RFC "Deny the overflowing_literals lint for the 2018 edition" (rust-lang/rfcs#2438).

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• Adjust documentation (see instructions on forge)

Unresolved questions:

None

[Centril]

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

[eddyb]

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

[varkor]

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
}

[ollie27]

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

[Centril]

Documentation is still todo

[pnkfelix]

triaged at T-compiler meeting. assigning to self to resolve doc issue(s).

[pnkfelix]

discussed with @Centril last night, mainly to find out what sort of documentation they expect to see here. It sounds like they would be satisfied with some sort of note in the Guide for the 2018 Edition...

[varkor]

Note that, as far as I can tell, there is no such documentation for any of the other lints whose default level depends on the edition, so if overflowing_literals is mentioned in the 2018 Edition Guide, then the others ought to be too.

[pnkfelix]

Following up on @varkor's point: While initiating an attempt to write the documentation, I tried to find any discussion of lints in "The Rust Programming Language" second edition. By this I mean "the linting system as a whole", or even "any particular lint." E.g. discussion or introduction of #[warn(bar)], #[allow(foo)], #[deny(baz)], etc

Maybe my search terms were ill-chosen, but I couldn't find any discussion of lints.

I'm not really inclined to spend time trying to document the changes to the default values (apart from e.g. the release notes) without having some documentation in a url-referable place that discusses the lint system as as whole.

[pnkfelix]

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 the docs team.

• (note: I left the T-lang tag on here, but the I-nominated tag is not targetted at T-lang...)

[steveklabnik]

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.

[ollie27]

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.

[Centril]

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

[TheDan64]

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?

[oli-obk]

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.

[TheDan64]

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