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

[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.

[bors]

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

[bors]

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

[traviscross]

In the interest of getting this closed out, in looking around GitHub for uses of 0o755 and similar things, I notice that, almost always, it's used directly as a literal argument to things like PermissionsExt::set_mode, PermissionsExt::from_mode, OpenOptionsExt::mode, DirBuilderExt::mode, etc.

If we scoped this down to linting against 0755-style literal arguments to these functions, that's a warning I could get behind, and I suspect that would capture most of the value here and have essentially zero false positives.

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[joshtriplett]

@traviscross There are a number of functions in the ecosystem that will want similar protection. Could we add some kind of #[expect_octal] attribute for a parameter, and then any integer literal with a leading zero passed to such a parameter will produce a warning?

[traviscross]

Yes, it is interesting to think how we might generalize this further. Probably -- again in the interest of getting this closed out with a Pareto win -- I'd prefer to just land the lint with a fixed list first and then think how we might extend it.

In searching around, there seemed a fairly finite number of ecosystem functions that would benefit from this, mostly from the nix crate as I recall. One option here, for now, would be to just recognize those well known crates and functions specially in the compiler, along with the ones in std, for the purposes of this lint. I'm not sure how we feel about this in general, but we did it, e.g., with the significant drop order lint (e.g., h/t @Urgau).

It occurs to me also that in these cases where we know the function is expecting a mode we could look for decimal literals matching a certain pattern even without leading zeros; e.g. mode(755) is going to be equally incorrect.

Then we could tackle a proposal for something like #[expect_octal] separately (or maybe #[expect_octal_mode], since that's the common case and allows even better targeting and diagnostics). (We might also consider whether the diagnostics namespace has a role here.) Of course, this starts getting rather niche, and it makes me think about what we've been talking about -- and what @nikomatsakis has been talking up in his conference talks -- about finding a way to allow crates to define their own lints. If, e.g., nix could define its own lints, I'm sure it could catch many more kinds of common errors that callers might make.

[bors]

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

[bors]

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

[bors]

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