Skip to content

Remove the From derive macro from prelude #145563

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 19, 2025

Conversation

Kobzol
Copy link
Member

@Kobzol Kobzol commented Aug 18, 2025

The new #[derive(From)] functionality (implemented in #144922) caused name resolution ambiguity issues (#145524). The reproducer looks e.g. like this:

mod foo {
    pub use derive_more::From;
}

use foo::*;

#[derive(From)] // ERROR: `From` is ambiguous
struct S(u32);

It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the From macro into the prelude. That will probably require #139493 to land.

I created a new module in core (and re-exported it in std) called from, where I re-exported the From macro. I think that since this is a new module, it should not have the same backwards incompatibility issue.

Happy to hear suggestions about the naming - maybe it would make sense as core::macros::from::From? But we already had a precedent in the core::assert_matches module, so I just followed suit.

Fixes: #145524

r? @petrochenkov

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 18, 2025
@rustbot
Copy link
Collaborator

rustbot commented Aug 18, 2025

Changes to the code generated for builtin derived traits.

cc @nnethercote

@rust-log-analyzer

This comment was marked as outdated.

To avoid backwards compatibility problems.
@Kobzol Kobzol force-pushed the remove-from-from-prelude branch from bcb8a5b to a6a760e Compare August 18, 2025 11:12
@Voultapher
Copy link
Contributor

If #139493 lands, this could just be core::From and in a future version From.

@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Aug 18, 2025

📌 Commit a6a760e has been approved by petrochenkov

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 18, 2025
@RalfJung
Copy link
Member

Wouldn't convert be the most sensible location, right next to the corresponding trait?

@Kobzol
Copy link
Member Author

Kobzol commented Aug 18, 2025

It can't be std::convert::From, because then existing code that already imported this path would suddenly start triggering an unstable derive_from feature.

bors added a commit that referenced this pull request Aug 19, 2025
Rollup of 19 pull requests

Successful merges:

 - #140956 (`impl PartialEq<{str,String}> for {Path,PathBuf}`)
 - #141744 (Stabilize `ip_from`)
 - #142681 (Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]`)
 - #142871 (Trivial improve doc for transpose )
 - #144252 (Do not copy .rmeta files into the sysroot of the build compiler during check of rustc/std)
 - #144476 (rustdoc-search: search backend with partitioned suffix tree)
 - #144567 (Fix RISC-V Test Failures in ./x test for Multiple Codegen Cases)
 - #144804 (Don't warn on never to any `as` casts as unreachable)
 - #144960 ([RTE-513] Ignore sleep_until test on SGX)
 - #145013 (overhaul `&mut` suggestions in borrowck errors)
 - #145041 (rework GAT borrowck limitation error)
 - #145243 (take attr style into account in diagnostics)
 - #145405 (cleanup: use run_in_tmpdir in run-make/rustdoc-scrape-examples-paths)
 - #145432 (cg_llvm: Small cleanups to `owned_target_machine`)
 - #145484 (Remove `LlvmArchiveBuilder` and supporting code/bindings)
 - #145557 (Fix uplifting in `Assemble` step)
 - #145563 (Remove the `From` derive macro from prelude)
 - #145565 (Improve context of bootstrap errors in CI)
 - #145584 (interpret: avoid forcing all integer newtypes into memory during clear_provenance)

Failed merges:

 - #145359 (Fix bug where `rustdoc-js` tester would not pick the right `search.js` file if there is more than one)
 - #145573 (Add an experimental unsafe(force_target_feature) attribute.)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit f44f963 into rust-lang:master Aug 19, 2025
10 checks passed
@rustbot rustbot added this to the 1.91.0 milestone Aug 19, 2025
rust-timer added a commit that referenced this pull request Aug 19, 2025
Rollup merge of #145563 - Kobzol:remove-from-from-prelude, r=petrochenkov

Remove the `From` derive macro from prelude

The new `#[derive(From)]` functionality (implemented in #144922) caused name resolution ambiguity issues (#145524). The reproducer looks e.g. like this:

```rust
mod foo {
    pub use derive_more::From;
}

use foo::*;

#[derive(From)] // ERROR: `From` is ambiguous
struct S(u32);
```

It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require #139493 to land.

I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue.

Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit.

Fixes: #145524

r? ``@petrochenkov``
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

New ambiguity with From derive macro in 2024 prelude
7 participants