Skip to content

Detect bad number of generics caused by bad derive - #160695

Open
estebank wants to merge 1 commit into
rust-lang:mainfrom
estebank:issue-160463
Open

Detect bad number of generics caused by bad derive#160695
estebank wants to merge 1 commit into
rust-lang:mainfrom
estebank:issue-160463

Conversation

@estebank

@estebank estebank commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

When a derive macro expands the annotated item's name directly using quote!, it keep the item's Span context (instead of having a new context). This means that the generic Span context machinery which provides feedback that an error happened due to a derive doesn't kick in.

If a derive macro isn't written to take into account the existence of type parameters, an error for "mismatched number of type parameters" will be emitted. We now detect the case when this happens due to the derive macro, and customize the output to point that out, as well as avoid giving suggestions that will always be wrong.

Partially address #160463 (this doesn't detect a nameres error caused by referencing type parameter within a derive).

error[E0107]: missing generics for enum `A`
 --> bar.rs:8:6
  |
7 | #[derive(A)]
  |          - it looks like this derive macro might not support annotating items with type parameters
8 | enum A<T> {
  |      ^
  • I did not use an LLM to create a change in this PR.
  • I used an LLM to create a change in this PR, and I have explained below how it was used.

r? @petrochenkov

@rustbot

rustbot commented Aug 7, 2026

Copy link
Copy Markdown
Collaborator

HIR ty lowering was modified

cc @fmease

@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs 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. labels Aug 7, 2026
@rust-log-analyzer

This comment has been minimized.

When a derive macro expands the annotated item's name directly using
`quote!`, it keep the item's Span context (instead of having a new
context). This means that the generic Span context machinery which
provides feedback that an error happened due to a derive doesn't kick
in.

If a derive macro isn't written to take into account the existence of
type parameters, an error for "mismatched number of type parameters"
will be emitted. We now detect the case when this happens due to the
derive macro, and customize the output to point that out, as well as
avoid giving suggestions that will always be wrong.
Comment on lines +561 to +563
"it looks like this derive macro might not support annotating items with type \
parameters",
);

@CenTdemeern1 CenTdemeern1 Aug 7, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it might be more accurate to say "generic parameters" as this applies to the other types of generic parameters too (lifetimes, const params)

View changes since the review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-run-make Area: port run-make Makefiles to rmake.rs 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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants