Warn against `mod lib;` in `main.rs`

[Kimundi]

Right now this is possible and compiles without warning:

Given a cargo crate with name "foo":

// src/lib.rs

// src/main.rs

mod lib;
fn main() {}

... even though we now have duplicated code in the library "foo" and the submodule "lib"

This can be confusing for a beginner because the code can still compile or just breaks "late" depending on what you do:

// src/lib.rs

pub struct Foo;

// src/main.rs

mod lib;

// either of those work (though not at the same time):
use foo::Foo;
use crate::lib::Foo;

fn main() {}

cargo or rustc should detect if we use lib.rs as a submodule, and warn or error against it.

---

This issue assumes 2018 edition without uniform paths syntax.

[eddyb]

cc @Centril @aturon @joshtriplett

[Centril]

This issue assumes 2018 edition without uniform paths syntax.

Does it not become moot then since that's what we are going to do?

[steveklabnik]

This would have to be done in Cargo, because only cargo even knows if there's another project being built.

additionally, it's a bit more general than this; while lib.rs is the default, you can name it anything.

[Kimundi]

@Centril: Just wanted to document what I based this issue on, since I was not sure if something influences the behavior here.

---

@steveklabnik: Right, it could be named anything, hm...

How about this: rustc gets a new flag used by cargo to inform it about "possible extern crate roots" or more general "possible extern source files". Cargo then looks at whether there are crates in the dependency chain that share source directories, and passes the module file paths as needed.

Whenever rustc sees a modulefile, it checks it against the list from the flag and emits an warning.

[neilyoung]

I'm astonished, that this simple problem is still not solved. See discussion here:

https://users.rust-lang.org/t/confusion-about-module-name-ambiguity/50512/9

[kadiwa4]

Since #94467, Rust warns against this.