New ambiguity with From derive macro in 2024 prelude

[ijackson]

Summary

I have a crate where I explicitly use derive_more::From (derive-more 1.x) and then use super::* in sub-modules. With current nightly, #[derive(From)] is now regarded as ambiguous.

I'm not using nightly features, so no derive_from (#144889). Looking for existing tickets I found #135672 but in that case the code was glob importing std modules, which I'm not doing, and #142448 which is about multiple globs, which I'm also not doing.

Code

https://salsa.debian.org/dgit-team/tag2upload-service-manager/-/tree/mini-sqlite-dump-0.1.0/mini-sqlite-dump?ref_type=tags
aka git clone https://salsa.debian.org/dgit-team/tag2upload-service-manager -b mini-sqlite-dump-0.1.0

https://docs.rs/crate/mini-sqlite-dump/0.1.0/builds/2421547

I expected to see this happen: it compiles with nightly like it does with stable.

Instead, this happened:

error[E0659]: `From` is ambiguous
   --> mini-sqlite-dump/src/text/reassemble.rs:22:30
    |
 22 | #[derive(Copy, Clone, Debug, 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
   --> mini-sqlite-dump/src/text/reassemble.rs:2:5
    |
  2 | 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 the derive macro defined here
   --> /volatile/rustcargo/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/prelude/mod.rs:161:13
    |
161 |     pub use core::prelude::rust_2024::*;
    |             ^^^^^^^^^^^^^^^^^^^^^^^^
 
For more information about this error, try `rustc --explain E0659`.

Version it worked on

1.90.0-beta.3

Version with regression

$ rustc +nightly -vV
rustc 1.91.0-nightly (2e2642e64 2025-08-16)
binary: rustc
commit-hash: 2e2642e641a941f0a1400c7827fd89aa86fef8f4
commit-date: 2025-08-16
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0

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

[Kobzol]

Thank you for the report! I think that we will have to only add the From macro to the prelude on an edition boundary, hmm 🤔 Even if we only added there if the unstable feature is enabled, we woulf just postpone this problem until it gets stabilized.

@petrochenkov Do you see any other way than an edition boundary? Could we somehow give precedence to an explicitly imported From macro, rather the one from the prelude?

[Kobzol]

I did some investigation and it seems that this runs into very similar problems as the assert_matches work. So I think that to avoid name resolution conflicts, we'll have to:

1. Only include the From macro in the prelude starting from the next edition
2. Add an unstable new module to core from which the macro could be imported before the next edition

Happy to hear other suggestions.

[apiraino]

Just to trace back to a PR: where does this originates? Are the mentioned issues related? cc @Kobzol @petrochenkov

[Kobzol]

Well, they are related in the sense that they talk about a similar issue, or a similar cause of the issue. But this specific issue was introduced in #144922. I'll send a fix.

[apiraino]

Assigning priority (discussion on Zulip).

@rustbot label -I-prioritize +P-critical