Is there a reason why context-sensitive identifiers are not banned for project name?

[HeWhoHeWho]

cargo new allows these identifiers to be project name, but likely to cause confusion.

Current banned keywords for project name (excluding weak keywords): [1]; [2]

Context-sensitive identifiers by category:

1. Project structure
   main, lib, init, config, setup, default, testing, etc.

2. Tooling
   cargo, rustc, build, target, deps, doc, bin, src, examples, tests, benches, out, etc.

3. Compiler
   std, core, alloc, proc_macro, compiler_builtins, panic_abort, panic_unwind, etc.

edit: Quick checked source code found 2 keywords missing from the current restricted name list: gen and union.

Appreciate enlightenment on this. Thanks.

[bjorn3]

std, core, alloc, proc_macro, compiler_builtins, panic_abort, panic_unwind, etc.

Most of these are banned from being uploaded to crates.io. The rest are internal crates that you wouldn't use as end user and in the case of compiler_builtins it is uploaded to crates.io by the rust project itself (we no longer update this version, but in the past you could use it as a dependency and in fact the standard library used to pull it from crates.io).

cargo, rustc, build, target, deps, doc, bin, src, examples, tests, benches, out, etc.

Cargo is uploaded to crates.io. Both the cargo and rustc package names have to be allowed by necessity as otherwise it would be impossible to build cargo and rustc.

main, lib, init, config, setup, default, testing, etc.

Aside from main and lib, none of these have any special meaning in rustc or cargo, so why should cargo ban it as package name?

[HeWhoHeWho]

Most of these are banned from being uploaded to crates.io. The rest are internal crates that you wouldn't use as end user and in the case of compiler_builtins it is uploaded to crates.io by the rust project itself (we no longer update this version, but in the past you could use it as a dependency and in fact the standard library used to pull it from crates.io).

Cargo is uploaded to crates.io. Both the cargo and rustc package names have to be allowed by necessity as otherwise it would be impossible to build cargo and rustc.

Aside from main and lib, none of these have any special meaning in rustc or cargo, so why should cargo ban it as package name?

Hi, thanks for enlightening me. My main concern is more on how to avoid names that may cause confusion. Basically, to sum up, none of the names I mentioned would affect Rust project build. How about main and lib that you set aside? Should the same treatment apply on them?

[weihanglo]

@rustbot transfer cargo

[weihanglo]

main and lib exist because they were designed as common entry points by Cargo. There is nothing stopping you from using them as package name. Even Cargo's test suite has that

cargo/tests/testsuite/workspaces.rs

Lines 1258 to 1261 in 8325770

	[package]
	name = "lib"
	version = "0.1.0"
	edition = "2015"

Personally I don't think a tool should have any restriction if those don't fail or potentially fail the build. People could have legitimate reasons to name a package main or build or doc. Actually the cargo team has discussed this recently and decided to lift some overly restricted rules for at least for cargo scripting -Zscript