Don't enforce snake_case for binary names

Currently, if you have a Cargo.toml like this:

[package]
name = "some_package"
version = "0.0.0"

[[bin]]
name = "somePackage"
path = "src/main.rs"

rustc will complain:

warning: crate `somePackage` should have a snake case name such as `some_package`
  |
  = note: #[warn(non_snake_case)] on by default

I understand why this is reasonable for library crates, to enforce a common naming convention for rust libraries and source code. But it doesn't make much sense to enforce this for binaries as well, as there is no real advantage to doing so (note that the crate name isn't camelCase, only the binary name is).

$ rustc --version
rustc 1.22.0-nightly (05f8ddc46 2017-10-07)

I've actually been digging in to this one and would be happy to take it on, if the Rust team agrees it should happen.

Right now, building a binary passes [[bin]]::name as the --crate-name argument. I've thought of two ways of tackling this.

Don't enforce the snake_case rule when building a binary
Add an optional --bin-name flag which can be used for naming the resulting binary. Defaults back to --crate-name. This would require coordination with cargo.

Personally, I prefer 2.

Policy should apply to executables and cdylib's alike.

It would also be great if you could turn off #[warn(non_snake_case)] for the crate name only. If I use #![allow(non_snake_case)] at the top-level, that disables the lint for my entire crate.

update Cargo.toml for fixing about snake_name convention

Policy should apply to executables and cdylib's alike.

It would also be great if you could turn off #[warn(non_snake_case)] for the crate name only. If I use #![allow(non_snake_case)] at the top-level, that disables the lint for my entire crate.

Agree, is there way to disable this warning for crate name while cargo build?

Don't treat Clippy warnings as errors

Make executable name snake case

This would be super simple to fix yet it is still a problem.

For example on Windows it is normal to have application names with capital letters and white spaces. We shouldn't need to manually rename the build artifact, so it would be nice to have an option to set a customized artifact name for exes and dlls.

Oh man, need this right now. Kustomize plugins look for a TitleCaseFileName.

To save having to do an extra rename, I'll just live with the warnings.

@oli-obk

Hi @oli-obk and @Manishearth,

You might be the relevant people to ask for guidance (or at least to redirect to other people).
This issue is very old and I didn't see any response from a Rust member.

Is it possible to avoid the non_snake_case warning for the build artifacts without using an #![allow(non_snake_case)] at the top-level, that disables the lint for the entire crate (which is really not desirable) ?

By build artifacts, I mean for crate-type = bin | cdylib | staticlib.
So for executable, static and dynamic system library.

(To me, the most important is the binary case)

The relevant code is

rust/compiler/rustc_lint/src/nonstandard_style.rs

Line 334 in b7d8c88

let crate_ident = if let Some(name) = &cx.tcx.sess.opts.crate_name {

I think it makes sense to avoid for bin. It's not as clear for the other two and I do not want to be the one to make that call. Make a PR, I guess?

@Manishearth

@Manishearth,

Thank you for the pointer!
I will try to make the PR soon.

Also FWIW this is just a suggestion, I do not know what the opinion of the relevant teams (the compiler team) is. So they may see the PR and decide that it is not the right route.

If you want to ask for a proper decision I suggest asking on the compiler team's channel on Zulip.

I looked at the code and it's more involved than what I expected...
Not sure I can do a good PR without extensively learn the way it is built.
It still seems doable quiet without too many trouble to someone that know the code base, especially for the bin case.

I am taking your advice and will reach out to the compiler team on Zulip (here the thread).

I would be against that many lints.

I think the purpose of the lint is to enforce style: first and foremost we should figure out what our style requirements are. It seems quite likely that enforcing this on binaries is not within our style needs, and not unlikely that the same is true for cdylibs and staticlibs. Once we settle on that set, those should simply not have lints: if there are people wishing to opt in to them being checked, they can file a clippy issue for a restriction lint, but let's not preemptively do work for users we are not sure exist.

Basically: whatever we figure out as the final warn set should be one lint, and everything else can be asked for individually later if there are users.

I'm not actually sure we need to worry about shallow stuff if we simply disable the lint for the three library types that have been brought up so far: it is quite reasonable for them to want to opt out; their naming is not from the Rust universe, it is from the C and universes. I think it's a valid problem to be solved, but I'm not sure we need to solve it immediately.

The good thing with separate lints is that, together with RFC 3389, they would allow a workspace-global configuration.

Yes, but the question remains to be answered if such a configuration is needed in the first place, and I don't want to preemptivel design for users we don't know exist.

The concrete needs I see here are:

binaries and C library types really do not need this convention
It is annoying to disable this lint for just the artifact name, which is needed for above^

So far I have yet to see a need to disable this lint for just the artifact name for reasons other than "I am building a binary/C library which has a different naming convention". I am also yet to see if there are other artifact types that need this.

My point earlier was that even though that the use case that made people open this issue is addressed well by #111130, one should go further than that and reconsider how it even came to that problem. In addition to merging #111130, one should try to address the useful feedback users gave about the inflexibility to configure lints. That was my earlier point.

But thinking of it, the same problem also exists if you have a non-snake case module name or function name, for whatever reason. In those cases, too, you can't easily disable the lint on that level only, keeping it enabled for variables declared inside the body.

Maybe, considering that this is such a general weakness, shallow is really the best solution. It would also help with making #[expect] be more precise (cc #54503).

I definitely think that splitting up the lint into one for each crate type is too much. At most one would have three lints: one for non-crate names, one for crate names that are for the rust ecosystem only, and a last one that is allow by default, for externally exposed crate names. Then people creating linux-only software can disallow that lint. But IMO it occurs so rarely that people put major characters in crate names exposed to the system, one doesn't really need a lint for that only. Most linux tooling is following the convention without there being lints that enforce it.

Thank you all for the replies.
Very interresting points.
I won't open an RFC.

Personally, I will be happy with #111130 getting merged as it solves my issue for the bin case.
Whenever I will encounter a case I need at work with a staticlib or a cdylib I will open a new PR for those as well.

@est31

@est31 yep

Though I'm somewhat against even three lints until someone comes up with a need that they would actually wish to enable the allow-by-default lint.

Two seems fine if we're not doing shallow, but for now I think downscoping the lint is an easy step and the broader shallow thing can be discussed at its own pace.

Rollup merge of rust-lang#111130 - GilShoshan94:issue-45127-fix, r=ol…

Rollup merge of rust-lang#121749 - jieyouxu:issue-45127-fix, r=petroc…

Auto merge of rust-lang#121749 - jieyouxu:issue-45127-fix, r=petroche…

Rollup merge of rust-lang#121749 - jieyouxu:issue-45127-fix, r=petroc…

Unrolled build for rust-lang#121749

Auto merge of rust-lang#130599 - jieyouxu:snake_case_binary_cleanup, …

Navigation Menu

Repository navigation

Don't enforce snake_case for binary names #45127

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Don't enforce snake_case for binary names #45127

Description

Activity

mikecluck commented on Oct 18, 2017

jethrogb commented on Dec 8, 2017

pipehappy1 commented on Jul 22, 2020

Zingam commented on Nov 20, 2021

NickLarsenNZ commented on Oct 5, 2022

GilShoshan94 commented on May 1, 2023

Manishearth commented on May 1, 2023

GilShoshan94 commented on May 1, 2023

Manishearth commented on May 1, 2023

GilShoshan94 commented on May 2, 2023

7 remaining items

Manishearth commented on May 9, 2023

Ltrlg commented on May 9, 2023

Manishearth commented on May 9, 2023

est31 commented on May 9, 2023

GilShoshan94 commented on May 9, 2023

Manishearth commented on May 9, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions