cargo init --bin creates a lib crate when crate source file is present

[BartMassey]

Problem

cargo init has a nice feature, in that if the file foo.rs exists in the directory foo that is being initialized, no src directory will be created and instead name = "foo" and path = "foo.rs" will be placed in Cargo.toml.

Unfortunately, cargo init --bin still produces a lib crate in this case.

Steps

1. mkdir foo
2. cd foo
3. touch foo.rs
4. cargo init --bin

The resulting Cargo.toml is

[package]
name = "foo"
version = "0.1.0"
authors = ["Me <me@example.com>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

[lib]
name = "foo"
path = "foo.rs"

I would strongly prefer getting [[bin]] instead of [lib] here.

Notes

Output of cargo version: cargo 1.51.0 (43b129a20 2021-03-16)

[BartMassey]

Apparently cargo init is deciding whether to create a binary or library crate depending on whether the source file (foo.rs above) contains a definition of main() — replace step 3 above with

echo 'fn main() {}' >foo.rs

and get a binary crate.

This is a reasonable heuristic, but I think the --bin and --lib flags should override it.

[Aelnor]

What if we have a file with fn main() and the user asks for a --lib here?
Do we fail the whole process?

I'm ready to fix this one if we have an answer

[ehuss]

I think an error would be fine, with hopefully a clear message that describes the conflict and maybe a suggestion on how to resolve it.

[BartMassey]

A warning would be best, I think. It's conceivable that a particularly obdurate user intends to have a function named main in their library: the warning should be sufficient for the normal case.

[ehuss]

A warning would fine, too! I don't feel strongly one way or the other.

[BartMassey]

Thank you!