Implement #[derive(From)]
#144922
Implement #[derive(From)]
#144922
Conversation
|
r? @SparrowLii rustbot has assigned @SparrowLii. Use |
rustbot
added
S-waiting-on-review
Kobzol
added
the
F-derive_from
|
☔ The latest upstream changes (presumably #145146) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
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
rustbot
added
S-waiting-on-author
|
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. |
|
Changes to the code generated for builtin derived traits. cc @nnethercote |
This comment has been minimized.
This comment has been minimized.
|
Good progress. The new error messages look good, thanks. |
|
Ok: squash the final 7 commits together, undo the formatting changes to |
|
@bors r=nnethercote |
bors
added
S-waiting-on-bors
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.
bors
added
S-waiting-on-author
Implements the
#[derive(From)]feature (tracking issue, RFC).It allows deriving the
Fromimpl on structs and tuple structs with exactly one field. Some implementation notes:spaneverywhere. 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.macro Fromtocore::convert, previously working code likeuse std::convert::Fromwould 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 (?).Ty::AstTy, because thefromfunction receives an argument with the type of the single field, and the existing variants of theTyenum couldn't represent an arbitrary type.