Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lint for functions/variables/etc using the same name as a type (str, u32, ...) #135196

Open
joshtriplett opened this issue Jan 7, 2025 · 5 comments
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-feature-request Category: A feature request, i.e: not implemented / a PR. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@joshtriplett
Copy link
Member

Code

fn func(u32: u32) {
    println!("{u32}");
}

fn main() {
    let u32 = 42;
    func(u32);

    let closure = |str: &str| {
        println!("{}", str.len());
    };
    closure("hello");
}

Current output

(none)

Desired output

warning: variable `u32` should use a name that doesn't conflict with a standard type
 --> src/main.rs:1:9
  |
1 | fn func(u32: u32) {
  |         ^^^ help: rename the identifier

Rationale and extra context

It's confusing to read code where str (or another standard type name) is used as an identifier. It also produces misleading syntax highlighting.

Other cases

Rust Version

rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1

Anything else?

No response

@joshtriplett joshtriplett added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. labels Jan 7, 2025
@fmease fmease added T-lang Relevant to the language team, which will review and decide on the PR/issue. C-feature-request Category: A feature request, i.e: not implemented / a PR. and removed A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 7, 2025
@Noratrieb
Copy link
Member

Noratrieb commented Jan 8, 2025

I don't like it, in my opinion str is a perfectly clear name for a string variable. Rust didn't make primitives keywords, so I don't see a reason why we shouldn't use the names. I don't think syntax highlighters should highlight primitive types in a special way, which would avoid this problem (r-a's highlighter doesn't).
I think this should be a pedantic clippy lint at most, I wouldn't want this to be a rustc lint.

@joshtriplett
Copy link
Member Author

This came up for me when searching for str in the codebase. Having it used as both a variable name and a type name made that much more challenging.

And many syntax highlighters do highlight these type names, and consider that a feature.

@ultimaweapon
Copy link

Naming a thing already hard. If this lint enabled by default it will even harder. One thing I like about Rust is I can name a thing without conflicts. e.g.:

mod str;

let foo = foo.bar();
let foo = foo.baz();

if let Some(v) = foo.str() {
} else if let Some(v) = foo.u32() {
}

@scottmcm
Copy link
Member

The particular case of this I think we should definitely lint on in bindings is

let Foo { x: u32 } = foo;

because that does something very different from what it looks like at first glance.


I wonder if an item-vs-binding distinction here could be reasonable.

I think type str = ...; is much worse than let str = ...;.

@ultimaweapon
Copy link

Another example from the project I'm working on is I need to create a struct to store character stats on my game like the following:

struct CharStats {
    pub str: u16,
    pub int: u16,
    pub vit: u16,
    ...
}

It is common to use str as an abbreviation for strength.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-feature-request Category: A feature request, i.e: not implemented / a PR. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants