Ambiguous import not detected

[sander2]

I tried this code (playground):

use a::*;
mod a {
    pub use b::*;
    mod b {
        pub const SOME_VALUE: u32 = 1;
    }

    pub use c::*;
    mod c {
        pub const SOME_VALUE: u32 = 2;
    }
}
fn main() {
    assert_eq!(SOME_VALUE, 1);
}

I expected to see this happen: an error like error[E0659]: SOME_VALUE is ambiguous

Instead, this happened: the code compiles and runs to completion.

If you put the use a::* after the mod a, the expected error is thrown.

Meta

This happens both on stable and nightly.

[SNCPlay42]

This fails to compile (after adapting to 2015 edition) on 1.14 and compiles on 1.15 and later.

1.15 made changes to the name resolution rules as described in RFC 1560. The relevant part seems to be:

Multiple unused imports

A name may be imported multiple times, it is only a name resolution error if that name is used. E.g.,

mod foo {
   pub struct Qux;
}

mod bar {
  pub struct Qux;
}

mod baz {
   use foo::*;
   use bar::*; // Ok, no name conflict.
}

In this example, adding a use of Qux in baz would cause a name resolution error.

Attempting to lookup a::SOME_VALUE does indeed error. However the compiler appears to fail to consider what happens if a name that is ambiguous due to multiple imports is glob-imported into another module. As far as I can tell, it should still be ambiguous, but instead it appears the first import of the name "wins".

@rustbot label A-resolve regression-from-stable-to-stable

(Ancient regression, I know, but this issue should probably have a priority assigned anyway)

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-medium

[SNCPlay42]

I think this is a duplicate of #47525.

[apiraino]

@SNCPlay42 would you prefer to close this in favor of #47525 (and working on that one instead)?

[sander2]

I think this is a duplicate of #47525.

I think you're right. I'm ok with closing this issue then. Just note that the linked issue has different tags (enhancement vs bug, no priority, and no regression tag) which may have contributed in it being an open issue for 4 years

[apiraino]

agreed, will update #47525 accordingly. Thanks!

[apiraino]

Closing this in favor of #47525