Skip to content

Remove the From derive macro from prelude#145563

Merged
bors merged 1 commit intorust-lang:masterfrom
Kobzol:remove-from-from-prelude
Aug 19, 2025
Merged

Remove the From derive macro from prelude#145563
bors merged 1 commit intorust-lang:masterfrom
Kobzol:remove-from-from-prelude

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.

Sign in to view
@Kobzol
Remove the From derive macro from prelude
a6a760e 
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

Voultapher commented Aug 18, 2025

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

@petrochenkov
Copy link
Contributor

petrochenkov commented Aug 18, 2025

@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

RalfJung commented Aug 18, 2025

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.

@Zalathar Zalathar mentioned this pull request Aug 19, 2025
Merged
bors added a commit that referenced this pull request Aug 19, 2025
@bors
Auto merge of #145589 - Zalathar:rollup-k97wtuq, r=Zalathar
8365fcb 
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
@rust-timer
Unrolled build for #145563
c6ed4b1 
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``
@apiraino apiraino mentioned this pull request Aug 19, 2025
Closed
@Zalathar
Copy link
Member

Zalathar commented Aug 19, 2025

Bors hasn't noticed that this was merged.

@bors r- retry

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 19, 2025
@Kobzol Kobzol deleted the remove-from-from-prelude branch August 19, 2025 11:55
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request Aug 20, 2025
@Zalathar
Rollup merge of rust-lang#145563 - Kobzol:remove-from-from-prelude, r…
870e8a0 
…=petrochenkov

Remove the `From` derive macro from prelude

The new `#[derive(From)]` functionality (implemented in rust-lang#144922) caused name resolution ambiguity issues (rust-lang#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 rust-lang#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: rust-lang#145524

r? ``@petrochenkov``
github-actions bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request Aug 25, 2025
@bors
Auto merge of #145589 - Zalathar:rollup-k97wtuq, r=Zalathar
9932c4b 
Rollup of 19 pull requests

Successful merges:

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

Failed merges:

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

r? `@ghost`
`@rustbot` modify labels: rollup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@petrochenkov petrochenkov

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

Milestone

1.91.0

Development

Successfully merging this pull request may close these issues.

New ambiguity with From derive macro in 2024 prelude

8 participants

@Kobzol @rustbot @rust-log-analyzer @Voultapher @petrochenkov @bors @RalfJung @Zalathar