the name `std` is defined multiple times

[Riateche]

The error happens on latest stable and nightly.
Steps to reproduce: cargo new --lib lib1;
src/lib.rs:

pub mod std {
}

tests/test1.rs:

use lib1;
fn main() {
}

cargo test returns error:

error[E0260]: the name `std` is defined multiple times
  |
  = note: `std` must be defined only once in the type namespace of this module

The error only happens if the module is named std (for instance, core and alloc work without error). The error is not produced if test1.rs doesn't use lib1 in any way. If test1.rs doesn't contain imports but uses the library directly (e.g. ::lib1::x()), the error is produced. cargo build always succeeds.

I don't know if this is supposed to be forbidden but the error message seems to be misleading.

[petrochenkov]

The second instance is extern crate std; injected implicitly.
The error could be better, yes.

[Riateche]

Where exactly is extern crate std; injected - in the library or in the test? Why does the library work on its own? Why does extern crate std conflict with lib1::std in the test?

[petrochenkov]

Ok, it turns out this is a legitimate bug, I misinterpreted it as a more commonly reported diagnostic issue.

extern crate std; is injected into both the library and the test, but only the first one causes the error.

If you set edition = "2015" in Cargo.toml, then you'll see the error immediately while compiling lib.rs - mod std conflicts with extern crate std.

On 2018 edition, however, extern crate std; is injected in more subtle way, as extern crate gensym(std); where gensym(std) is some unique symbol that still has the string representation "std", but doesn't clash with anything in the same crate.
Unfortunately, gensym(std) turns into "just std" after encoding into metadata in the compiled library liblib1.rlib (this is the bug).
So, when we load that library from the test it looks like the library defines two conflicting items.

[petrochenkov]

The solution is to either encode gensyms/hygiene into metadata properly (this is a large task and a long standing issue), or come up with some hack preventing the injected extern crate std specifically from being encoded (it doesn't really need to be encoded).

[petrochenkov]

Fixed in #59296