Detect bad number of generics caused by bad derive

[estebank]

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 items with generic 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]

HIR ty lowering was modified

cc @fmease

[petrochenkov]

The impl's span here is not copied from the input, so it should be marked as coming from a derive.
enum_map_derive uses a different quote, but there the impl should also be marked as coming from a derive.

So if we want to suggest adding missing generic parameters to an impl, we should check the impl's span, not some specific ident's span. And if the impl's span comes from a derive (or an external macro in general), we don't suggest adding the generic parameter.
I'm not sure why the conditions checking things like source_equal are necessary.
is_automatically_derived is also unreliable, many user-defined derives don't add that attribute, if the impl's span is from a derive, then checking for is_automatically_derived is redundant.

View changes since the review

[estebank]

The case where source_equal comes into play is when you have a derive on a type with a duplicated name, where the expansion resolves the impl to be about the other type and not the one being expanded:

error[E0107]: struct takes 0 lifetime arguments but 1 lifetime argument was supplied
  --> $DIR/multiple-types-with-same-name-and-derive-default-133965.rs:5:10
   |
LL | #[derive(Default)]
   |          ^^^^^^^ expected 0 lifetime arguments
...
LL | struct NonGeneric<'a, const N: usize> {}
   |                   -- help: remove the lifetime argument
   |
note: struct defined here, with 0 lifetime parameters
  --> $DIR/multiple-types-with-same-name-and-derive-default-133965.rs:3:8
   |
LL | struct NonGeneric {}
   |        ^^^^^^^^^^

I will have to detect that case regardless, so that I can silence it because it is completely redundant/useless.

[estebank]

After #162831 lands, I think I can remove the source_equals check safely, but I'd keep it just in case as it makes sure that we are indeed pointing at the type's ident.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.