Lint against leading 0 in integer literals

[huonw]

A literal like 0111 looks like an octal literal in C, but is actually decimal in Rust (octal would be0o111). This is a footgun, and so seems like something that could be trivially checked for.

(I suppose this could be a "clippy" lint, but that seems like it would lose most of the benefit: it seems to me that most people who encounter this will be just starting out, not invested in running external, third-party commands using nightly.)

[oli-obk]

There are lots of lints in clippy that would most help new rustaceans. If there were a process to move lints to rustc as long as they have proven themselves as non-opinionated and false-positive-free, then a lot of people could start benefiting from clippy's lints.

[oli-obk]

One thing speaking against doing this in clippy is that this specific lint needs to be done during parsing, because the ast does not get the string representation of a literal, but only a numeric representation. Clippy would have to use the span to obtain the text and then act on the text.

Alternatively the ast could be changed to represent the original text, and ast -> hir lowering could extract the numerical representation.

[oli-obk]

cc @Manishearth @llogiq

[llogiq]

I don't see a problem with looking at the span of a literal, so we could well develop the lint in clippy, and move it to rustc later.

AFAIR, the core team has expressed they don't want to increase the number of included lints to keep it manageable (and probably also to keep compile time from ballooning 😄). The longer we go without merging lints into rustc, the more I think of clippy as -Wall for Rust...

[Manishearth]

Works in clippy. There are a lot of lints in clippy specifically for newcomers and stuff. That was in fact the original scope/goal, but it has expanded since then.

Also, zero-setup cargo install clippy is happening soon, so I suspect clippy to gain more use amognst newcomers.

[therealbstern]

I'm in favor of this being a compile time warning that could be disabled with #allow, just like the dead_code warning. I think this will bite a lot of newcomers who won't know to run clippy.

[Nicholas-Baron]

I am going to assume that since this topic has had little discussion for around 3-4 years and the issue still persists (see this playground), that it has been "agreed to by silence".

Two locations in the rustc_parse crate seem to be good places to try implementing this warning.
0o191 errors with an 'invalid digit' error, produced here (lexer/mod.rs). However, there is also an 'invalid suffix' error, produced in a different file (parser/expr.rs).

The main questions to answer is: Where should this warning be emitted?
Ideally, it should be produced

1. Before rustc "loses" knowledge of the raw characters of the token
2. Where other invalid numbers (like 0o191 or 0xG00D) are caught

[GrigorenkoPV]

@rustbot claim