You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The error happens on latest stable and nightly.
Steps to reproduce: cargo new --lib lib1; src/lib.rs:
pubmod std {}
tests/test1.rs:
use lib1;fnmain(){}
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.
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?
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.
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).
Activity
petrochenkov commentedon Mar 16, 2019
The second instance is
extern crate std;injected implicitly.The error could be better, yes.
Riateche commentedon Mar 16, 2019
Where exactly is
extern crate std;injected - in the library or in the test? Why does the library work on its own? Why doesextern crate stdconflict withlib1::stdin the test?petrochenkov commentedon Mar 18, 2019
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"inCargo.toml, then you'll see the error immediately while compilinglib.rs-mod stdconflicts withextern crate std.On 2018 edition, however,
extern crate std;is injected in more subtle way, asextern crate gensym(std);wheregensym(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 "juststd" after encoding into metadata in the compiled libraryliblib1.rlib(this is the bug).So, when we load that library from the test it looks like the library defines two conflicting items.
petrochenkov commentedon Mar 18, 2019
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 stdspecifically from being encoded (it doesn't really need to be encoded).petrochenkov commentedon Mar 19, 2019
Fixed in #59296
Rollup merge of rust-lang#59296 - petrochenkov:stdup, r=estebank