Implement `#[derive(From)]`#144922

Kobzol · 2025-08-04T19:18:51Z

Implements the #[derive(From)] feature (tracking issue, RFC).

It allows deriving the From impl on structs and tuple structs with exactly one field. Some implementation notes:

I wasn't exactly sure which spans to use in the derive generating code, so I just used span everywhere. I don't know if it's the Right Thing To Do. In particular the errors when #[derive(From)] is used on a struct with an unsized field are weirdly duplicated.
I had to solve an import stability problem, where if I just added the unstable macro From to core::convert, previously working code like use std::convert::From would suddenly require an unstable feature gate, because rustc would think that you're trying to import the unstable macro. @petrochenkov suggested that I add the macro the the core prelude instead. This has worked well, although it only works in edition 2021+. Not sure if I botched the prelude somehow and it should live elsewhere (?).
I had to add Ty::AstTy, because the from function receives an argument with the type of the single field, and the existing variants of the Ty enum couldn't represent an arbitrary type.

rustbot · 2025-08-04T19:18:56Z

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

tests/ui/feature-gates/feature-gate-derive-from.rs

bors · 2025-08-10T03:47:03Z

☔ The latest upstream changes (presumably #145146) made this pull request unmergeable. Please resolve the merge conflicts.

nnethercote

On the right track, but a few things need fixing.

There is a test called tests/ui/deriving/deriving-all-codegen.rs which tests the output of all builtin derives. It's really useful to have a test that shows the actual output, so that minor changes can be seen.

From should be added to that file. A lot of the structs don't have a single field, it would be worth adding/moving some of the ones from deriving-from.rs to it.

The derive(...) lists are in mostly-alphabetical order, so I would put From in between Default and Hash.

@rustbot author

tests/ui/deriving/deriving-from-wrong-target.rs

compiler/rustc_builtin_macros/src/deriving/from.rs

tests/ui/deriving/deriving-from-wrong-target.rs

Kobzol · 2025-08-15T08:31:12Z

I tried to resolve review remarks, and improve the error message(s). Before fixing tests, I'd like to know your opinion on the current errors.

rustbot · 2025-08-15T08:34:51Z

Changes to the code generated for builtin derived traits.

cc @nnethercote

compiler/rustc_builtin_macros/src/deriving/from.rs

tests/ui/deriving/deriving-all-codegen.rs

nnethercote · 2025-08-15T09:25:08Z

Good progress. The new error messages look good, thanks.

nnethercote · 2025-08-15T09:49:56Z

Ok: squash the final 7 commits together, undo the formatting changes to deriving-all-codegen.rs, and r=me.

Kobzol · 2025-08-15T11:34:56Z

@bors r=nnethercote

bors · 2025-08-15T11:34:58Z

📌 Commit 1f3a747 has been approved by nnethercote

It is now in the queue for this repository.

Rollup of 11 pull requests Successful merges: - #143717 (Add `Default` impls for `Pin`ned `Box`, `Rc`, `Arc`) - #144054 (Stabilize as_array_of_cells) - #144907 (fix: Reject async assoc fns of const traits/impls in ast_passes) - #144922 (Implement `#[derive(From)]`) - #144963 (Stabilize `core::iter::chain`) - #145436 (fix(tests/rmake/wasm-unexpected-features): change features from `WASM1` to `MVP`) - #145453 (Remove duplicated tracing span in bootstrap) - #145454 (Fix tracing debug representation of steps without arguments in bootstrap) - #145455 (Do not copy files in `copy_src_dirs` in dry run) - #145462 (Stabilize `const_exposed_provenance` feature) - #145466 (Enable new `[range-diff]` feature in triagebot) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #144922 - Kobzol:derive-from, r=nnethercote Implement `#[derive(From)]` Implements the `#[derive(From)]` feature ([tracking issue](#144889), [RFC](rust-lang/rfcs#3809)). It allows deriving the `From` impl on structs and tuple structs with exactly one field. Some implementation notes: - I wasn't exactly sure which spans to use in the derive generating code, so I just used `span` everywhere. I don't know if it's the Right Thing To Do. In particular the errors when `#[derive(From)]` is used on a struct with an unsized field are weirdly duplicated. - I had to solve an import stability problem, where if I just added the unstable `macro From` to `core::convert`, previously working code like `use std::convert::From` would suddenly require an unstable feature gate, because rustc would think that you're trying to import the unstable macro. `@petrochenkov` suggested that I add the macro the the core prelude instead. This has worked well, although it only works in edition 2021+. Not sure if I botched the prelude somehow and it should live elsewhere (?). - I had to add `Ty::AstTy`, because the `from` function receives an argument with the type of the single field, and the existing variants of the `Ty` enum couldn't represent an arbitrary type.

jhpratt · 2025-08-16T05:16:52Z

still in queue; merged in #145475

@bors r-

Implement `#[derive(From)]` Implements the `#[derive(From)]` feature ([tracking issue](rust-lang#144889), [RFC](rust-lang/rfcs#3809)). It allows deriving the `From` impl on structs and tuple structs with exactly one field. Some implementation notes: - I wasn't exactly sure which spans to use in the derive generating code, so I just used `span` everywhere. I don't know if it's the Right Thing To Do. In particular the errors when `#[derive(From)]` is used on a struct with an unsized field are weirdly duplicated. - I had to solve an import stability problem, where if I just added the unstable `macro From` to `core::convert`, previously working code like `use std::convert::From` would suddenly require an unstable feature gate, because rustc would think that you're trying to import the unstable macro. `@petrochenkov` suggested that I add the macro the the core prelude instead. This has worked well, although it only works in edition 2021+. Not sure if I botched the prelude somehow and it should live elsewhere (?). - I had to add `Ty::AstTy`, because the `from` function receives an argument with the type of the single field, and the existing variants of the `Ty` enum couldn't represent an arbitrary type.

…=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``

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``

…=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``

This fixes an error from nightly. The trouble is that with nightly, there's a now a [derive macro for From][issue]. That doesn't cause a conflict when we `use derive_more::From`, but it _does_ cause a conflict when we import `derive_more::From` via `use internal_prelude::*`. So as a solution, we just import `derive_more::From` explicitly. Closes #2124 [issue]: rust-lang/rust#144922

…nkov Remove the `From` derive macro from prelude The new `#[derive(From)]` functionality (implemented in rust-lang/rust#144922) caused name resolution ambiguity issues (rust-lang/rust#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/rust#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/rust#145524 r? ``@petrochenkov``

rustbot assigned SparrowLii Aug 4, 2025

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 4, 2025

Kobzol mentioned this pull request Aug 4, 2025

Tracking Issue for derive_from (RFC 3809) #144889

Open

7 tasks

Kobzol added the F-derive_from Feature gate for #[derive(From)] built-in derive macro (RFC 3809). label Aug 4, 2025

Kivooeo reviewed Aug 5, 2025

View reviewed changes

tests/ui/feature-gates/feature-gate-derive-from.rs Show resolved Hide resolved

Kobzol force-pushed the derive-from branch from 964d6e3 to 60eac40 Compare August 11, 2025 18:41