Derive macro glob import flagged as ambiguous with implicit prelude import

[jgeibel-burns]

Code

I tried this code:

use derive_more::From; // version = "2.1.0", features = ["from"]

mod inner {
    use super::*;
    
    #[derive(From)]
    struct Demo {
        one: u8,
        two: u8,
    }
}

I expected to see this happen: compile successfully, matching the behavior on stable and nightly-2025-12-14. I expect that implicit imports from the prelude would be lower priority (and thus not ambiguous) compared to glob imports written by the user.

Instead, this happened:

$ cargo +nightly-2025-12-15 check
error[E0659]: `From` is ambiguous
 --> src/lib.rs:6:14
  |
6 |     #[derive(From)]
  |              ^^^^ ambiguous name
  |
  = note: ambiguous because of a conflict between a name from a glob import and an outer scope during import or macro resolution
note: `From` could refer to the derive macro imported here
 --> src/lib.rs:4:9
  |
4 |     use super::*;
  |         ^^^^^^^^
  = help: consider adding an explicit import of `From` to disambiguate
  = help: or use `self::From` to refer to this derive macro unambiguously
note: `From` could also refer to a derive macro from prelude
 --> library/std/src/prelude/mod.rs:161:12

For more information about this error, try `rustc --explain E0659`.
error: could not compile `rust-nightly-2025-12-17-breakage-demo` (lib) due to 1 previous error

Version it worked on

It most recently worked on: nightly-2025-12-14

Version with regression

cargo +nightly-2025-12-15 --version --verbose:

cargo 1.94.0-nightly (e91b2baa6 2025-12-13)
release: 1.94.0-nightly
commit-hash: e91b2baa632c0c7e84216c91ecfe107c37d887c1
commit-date: 2025-12-13
host: x86_64-unknown-linux-gnu
libgit2: 1.9.1 (sys:0.20.2 vendored)
libcurl: 8.15.0-DEV (sys:0.4.83+curl-8.15.0 vendored ssl:OpenSSL/3.5.4)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: Ubuntu 26.4.0 (resolute) [64-bit]

@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged

[ehuss]

This seems to have changed in #146348 cc @jdonszelmann.

Also cc @petrochenkov just FYI since I initially thought this could be related to some of your recent work, but it does not appear to be. And @yaahc since you now have a lot of ambiguity expertise 😉 .

[jdonszelmann]

Hmmm. I honestly can't quite believe that. I'll investigate tomorrow, but I can't quite see how this could even slightly be related. But: I'm dumb sometimes, maybe I messed something up 😭

[yaahc]

I fully expected this to be caused by #139493 but that isn't even merged yet, investigating.

[ehuss]

Yea, I'm a little surprised, too. You can double-check: for me 2cd4ee6 passes but 3f4dc1e fails.

[yaahc]

https://github.com/rust-lang/rust/pull/146348/files#diff-a6f9f476d41575b19b399c6d236197355556958218fd035549db6d584dbdea1dR126 is the culprit, same issue as in the PR I linked.

I expected to see this happen: compile successfully, matching the behavior on stable and nightly-2025-12-14. I expect that implicit imports from the prelude would be lower priority (and thus not ambiguous) compared to glob imports written by the user.

So as I understand it before #146348 there was no candidate for derive From coming from the prelude. The once there is a candidate from the prelude it won't matter if it's lower priority, because you're trying to resolve a macro through a glob import the only thing that matters is that it's from an "outer scope", and all of the preludes count as outer scopes for the purposes of that ambiguity error¹.

I'm not as familiar with how unstable features affect name-res but naively I would have hoped that so long as you didn't enable the derive-from feature that it would not show up as ambiguous, but I'm guessing that's not the case given the observed behavior. Maybe that's something that only occurs for names resolved during primary resolution and not expansion-time resolution names.

Footnotes

1. https://github.com/rust-lang/reference/blob/master/src/names/name-resolution.md#ambiguities scroll down a bit until you get to glob-vs-outer. Unfortunately I can't link to it directly yet because we're still waiting on a subtree sync between rust-lang/rust and rust-lang/reference. ↩

[yaahc]

I'm trying to look through @jdonszelmann's PR to understand why the change introducing the From derive to the prelude was necessary and not really coming up with an explanation. Hopefully we can just revert that small part of the change to resolve the issue assuming it is indeed not a critical part of that change.

[jdonszelmann]

Oh! I understand now. So for a little bit I think we introduced it to the prelude and then removed it again a few months back. I remember this happening, and since my pr has been open for about a year now I've veen continuously rebasing it. I think it's simply a rebasing error on my part which then wasn't caught in review. Feel free to revert that part and assign me :3