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.

[Skgland]

Given that in test1 and test2 Trait is never explicitly named I am surprised that it doesn't just act as

fn test3() {
    use m1::Trait as _;
    use m2::Trait as _;
    0u8.method1();
    0u8.method2();
}

fn test4() {
    use m2::Trait as _;
    use m1::Trait as _;
    0u8.method1();
    0u8.method2();
}

i.e. I would have expected only explicitly naming Trait to be ambiguous.

[petrochenkov]

@Skgland

That's the second option from #147992 (comment).

Making them both in scope should also be feasible, but it needs some new infra that we don't have now.

Given the breakage from #147995 and the complexity of mitigating it, this may be a simpler option.
If we choose this option, then we should most definitely fix #144993 as well.

[petrochenkov]

As the experiment results in #148946 (comment) show, we may not be able to treat

use module::*; // import `Trait`

as

use module::Trait as _;

for the purpose of determining which traits are in scope, at least on the current edition.

People actually rely on the fact that the explicit import in

use first_trait::*; // import `Trait`
use another_trait::Trait;

removes the first trait from the scope, which wouldn't happen in the underscore import model.