The set of traits in scope behaves unpredictably in presence of ambiguous glob imports

[petrochenkov]

I tried this code:

mod m1 {
    pub trait Trait {
        fn method1(&self) {}
    }
    impl Trait for u8 {}
}
mod m2 {
    pub trait Trait {
        fn method2(&self) {}
    }
    impl Trait for u8 {}
}

fn test1() {
    // Create an ambiguous import for `Trait` in one order
    use m1::*;
    use m2::*;
    0u8.method1(); // OK
    0u8.method2(); // ERROR no method named `method2` found for type `u8` in the current scope
}

fn test2() {
    // Create an ambiguous import for `Trait` in another order
    use m2::*;
    use m1::*;
    0u8.method1(); // ERROR no method named `method1` found for type `u8` in the current scope
    0u8.method2(); // OK
}

fn main() {}

I expected to see this happen: either none of the Traits is in scope, or both of them are in scope.

Instead, this happened: the resolution depends on glob import order, which is supposed to never happen.

Meta

rustc --version --verbose:

rustc 1.92.0-nightly (f04e3dfc8 2025-10-19)
binary: rustc
commit-hash: f04e3dfc87d7e2b6ad53e7a52253812cd62eba50
commit-date: 2025-10-19
host: x86_64-pc-windows-gnu
release: 1.92.0-nightly
LLVM version: 21.1.3

[petrochenkov]

In practice the resolution depends on which of the glob imports first gets resolved and written into its parent module.
If no macros are involved, then it's the first import in source code order, if macros are involved, then less macro-expanded import may win instead, even if goes after the more macro-expanded one.
This is something we want to avoid not just because of the general principle of import order-independency, but for practical things like parallel import resolution as well.

Both traits NOT being in scope would be more in line with our general treatment of glob-vs-glob ambiguities (they produce errors on any other access).
Making them both in scope should also be feasible, but it needs some new infra that we don't have now.

@lcnr this is somewhat similar to #144993 that you found curious.

[petrochenkov]

This is a stable-to-stable regression from Rust 1.33 (!), the traits were considered not in scope before that.
Back then the internal representation of ambiguous imports changed, I can try finding the PR (it was my work), but it'll take some time.
Upd: found it - #57199.

[petrochenkov]

Fixed in #147995.