Order of glob imports affects whether an ambiguity is reported

[SNCPlay42]

The following code (2015 edition, a subset of /src/test/ui/imports/duplicate.rs, playground) compiles:

mod a {
    pub fn foo() {}
}

mod b {
    pub fn foo() {}
}

mod f {
    pub use a::*;
    pub use b::*;
}

mod g {
    pub use a::*;
    pub use f::*;
}

fn main() {
    g::foo();
}

If you reorder the glob imports in g, it does not compile (playground):

error[E0659]: `foo` is ambiguous
  --> src/main.rs:20:8
   |
20 |     g::foo();
   |        ^^^ ambiguous name
   |
   = note: ambiguous because of multiple glob imports of a name in the same module
note: `foo` could refer to the function imported here
  --> src/main.rs:10:13
   |
10 |     pub use a::*;
   |             ^^^^
   = help: consider adding an explicit import of `foo` to disambiguate
note: `foo` could also refer to the function imported here
  --> src/main.rs:11:13
   |
11 |     pub use b::*;
   |             ^^^^
   = help: consider adding an explicit import of `foo` to disambiguate

Both versions failed to compile prior to 1.32.0.

I found this while looking at #97584/#47525, which looks very related, but regressed earlier (1.15) - I have a WIP fix for that issue, but it fails on the linked UI test because it makes this error again. I'm mostly opening this to double-check that this change wasn't deliberate (since the change to the UI test's output was blessed).

@rustbot label C-bug T-compiler A-resolve regression-from-stable-to-stable

[SNCPlay42]

I initially thought that perhaps the unambiguous import of a::foo via the glob pub use a::*; in g is supposed to "win" against the glob import of the ambiguous f::foo, but then I don't see why this should be order dependent.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium

[SNCPlay42]

I see on zulip there was some confusion surrounding the edition:

The 2018+ edition version of this code:

mod a {
    pub fn foo() {}
}

mod b {
    pub fn foo() {}
}

mod f {
    pub use crate::a::*;
    pub use crate::b::*;
}

mod g {
    pub use crate::a::*;
    pub use crate::f::*;
}

fn main() {
    g::foo();
}

still behaves the same way as the 2015 code, in that it compiles, but shouldn't (IMO), and is still dependent on the order of the uses in g in whether it errors or not.

[bvanjoi]

related: #113242
related: #113099