-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
make easier/possible to detect derive attributes after expansion #45216
Copy link
Copy link
Open
Labels
A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
In the spirit of #44942, it would be nice if the
missing_debug_implementationsandmissing_copy_implementationslints suggested adding a derive attribute (in the case where one does not already exist) or addingDebug(respectivelyCopy) to the list of traits in the derive attribute (in the case where it already exists). (This mostly for the sake of RLS and other tools, but the span highlighting is pretty, too.) But while the lints (obviously, necessarily) know how to look up whether the trait has been implemented, it's not clear how to make them detect an existing derive attribute (and its span):cx.tcx.get_attrsdoesn't work because we apparently strip off the attribute during expansion(it looks like this happens twice, which is confusing: 1 2). But I can't modify the expansion code because I'm still not smart enough to understand it.