Warn about C-style octal literals

[GrigorenkoPV]

Uplifts clippy::zero_prefixed_literal as leading_zeros_in_decimal_literals, warn-by-default.

---

The leading_zeros_in_decimal_literals lint detects decimal integral literals with leading zeros.

Example

fn is_executable(unix_mode: u32) -> bool {
    unix_mode & 0111 != 0

Explanation

In some languages (including the infamous C language and most of its family), a leading zero marks an octal constant. In Rust however, a 0o prefix is used instead.
Thus, a leading zero can be confusing for both the writer and a reader.

In Rust:

fn main() {
    let a = 0123;
    println!("{}", a);
}

prints 123, while in C:

#include <stdio.h>

int main() {
    int a = 0123;
    printf("%d\n", a);
}

prints 83 (as 83 == 0o123 while 123 == 0o173).

---

Notes

Compared to the Clippy lint, this will not warn if the literal is unambiguous, i.e. it has 8's or 9's in it (clearly not octal) or it is <10 (in this case the value does not depend on the base).

Closes #33448
r? @ghost

[GrigorenkoPV]

@rustbot ready

r? @Urgau

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[Urgau]

This looks fine to me. Let's nominate it for T-lang fcp (which could unfortunatly take months, due to T-lang backlog).

I've taken the liberty to adjust the PR description to include the lint description as well, in order to clearly see what the lint does. Feel free to update it if you update the one in the PR.

@rustbot labels -S-waiting-on-review +S-waiting-on-team +I-lang-nominated

[GrigorenkoPV]

Does an allow-by-default rustc lint has better discoverability than a warn-by-default clippy lint?

[nikomatsakis]

@rfcbot reviewed

[nikomatsakis]

@rfcbot concern allow-by-default

Per @joshtriplett's comment, the FCP has changed to allow-by-default, but the OP on the PR (and afaik the impl) is still warn-by-default. Filing this concern until those are updated.

[nikomatsakis]

Regarding the lint, I think my ideal would probably be to have this lint as allow-by-default and a more narrowly targeted one as allow-by-default, with a "subtyping" relationship -- I guess this means a leading_zero lint group or something?

[bors]

☔ The latest upstream changes (presumably #136070) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #127541) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #137348) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #137752) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #138761) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #119220) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #139983) made this pull request unmergeable. Please resolve the merge conflicts.

[tmandry]

+1 for a narrowly-scoped lint that only fires on patterns that look like file modes and other very common uses of octal. For that I think the upside (likelihood times benefit) of finding bugs far exceeds the downside (likelihood times inconvenience) of adding a blanket allow if a false positive slaps you and you don't like it.

I don't see why we would also have an allow-by-default lint that blanket warns on leading zeros. If we have the narrowly scoped version, that starts to sound more like a clippy lint in the style category.