feature: add the "Recursively add derive" assist #18118
Open
+1,223
−8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
the
S-waiting-on-review
| match list { | ||
| ast::FieldList::RecordFieldList(list) => { | ||
| record = Some( | ||
| list.fields().filter_map(|field| ctx.sema.resolve_type(&field.ty()?)?.as_adt()), |
There was a problem hiding this comment.
It seems unfortunate to exclude things only because they are not ADT or not local, e.g. references will be excluded, and Box, and Vec, while all may have a conditional implementation for arbitrary types.
A better strategy will be when the type is non-local, to instead include its generic parameters (or their generic parameters, recursively). An even better (but harder) strategy will be to look if the type has a conditional implementation and what are its conditions (this doesn't have to go in the initial implementation, though).
There was a problem hiding this comment.
I completely forgot about that, I'll look into it 👍
davidbarsky
reviewed
Sep 16, 2024
IvarWithoutBones
force-pushed
the
recursively-add-derive
branch
from
ccb3e6a
to
f6b20fd
Compare
|
Thanks for the reviews, I've fixed most comments. Supporting non-ADTs and using |
This commit adds the core::hash::Hash derive macro to the prelude, just like rustc does. They define the macro in a private core::hash::macros module, presumably to differentiate between the macro and trait (who otherwise share the same path). Only the macro is in the prelude, which minicore now mirrors. I've also added support for multiple "line regions" in minicore, as the prelude re-export needs both "hash" and "derive". The syntax looks as follows: "// :hash, derive".
IvarWithoutBones
force-pushed
the
recursively-add-derive
branch
from
f6b20fd
to
b551aa8
Compare
DropDemBits
reviewed
Sep 19, 2024
This introduces a new assist that adds the derive attributes from a struct or enum to the types of its fields, recursively. It is recursive in the sense that the fields of field types are also considered. The derive attributes will be copied over if the field type meets the following criteria: * It resides within the same workspace as the "top-level" type, to avoid editing the crate registry. * It does not already have the same derive attribute. * It does not have a manual implementation of the trait. The last criteria is a bit of a guess since it isn't possible to know what trait implementation(s) a derive macro generates. If a trait has the same name as the derive macro and the top-level type (which already has the derive attribute) implements it, it'll be used to check for manual impls. This seems to work well in practice.
IvarWithoutBones
force-pushed
the
recursively-add-derive
branch
from
b551aa8
to
c8b9781
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This introduces a new assist that adds the derive attributes from a struct or enum to the types of its fields, recursively:
The derive attributes will be copied over if the field type meets the following criteria:
The last criteria is a bit of a guess since it isn't possible to know what trait implementation(s) a derive macro generates. If a trait has the same name as the derive macro and the top-level type (from which we're copying the derive attribute) implements it, it'll be used to check for manual impls. This seems to work well in practice :)
Fixes #12330