Conversation
``` error[E0425]: cannot find type `T` in this scope --> $DIR/derive-macro-unsupported-type-params.rs:11:13 | LL | #[derive(A)] | - in this derive macro ... LL | Variant(T), | ^ not found in this scope ```
|
r? @TaKO8Ki rustbot has assigned @TaKO8Ki. Use Why was this reviewer chosen?The reviewer was selected based on:
|
9450ce6 to
e17ca3e
Compare
| fn detect_resolution_error_in_derive(&self, err: &mut Diag<'_>, span: Span) { | ||
| if let Some(item) = self.diag_metadata.current_item | ||
| && !item.span.eq_ctxt(span) | ||
| && item.span.in_derive_expansion() | ||
| { | ||
| // `item` comes from a `#[derive()]`, but the error `span` doesn't, which means that the | ||
| // derive is referencing a name coming from the annotated item. If the item exists, then | ||
| // the derive macro itself is buggy. If the item exists, then an error will have already | ||
| // been emitted while evaluating the annotated item itself. | ||
| err.span_label(item.span, "in this derive macro"); | ||
| } | ||
| } |
There was a problem hiding this comment.
I'd originally made this delay the error as bug, so that the resolve error would not be present, under the assumption that other errors would already have been emitted (if it was a non-existing item, we'd have an error when evaluating the item itself, if a proc-macro error, we have the other errors)...
| } | ||
| }; | ||
| tokens | ||
| } |
There was a problem hiding this comment.
...but this macro is written such that if the name resolution error isn't emitted...
| #[derive(C)] | ||
| enum C<T> { | ||
| Variant(T), | ||
| //~^ ERROR: cannot find value `T` in this scope | ||
| //~| ERROR: cannot find type `T` in this scope | ||
| } |
There was a problem hiding this comment.
...and this is the only code in the crate being built, we end up with an ICE.
This is why I'm adding context instead of silencing. I'd love it if we could come up with a strategy where we silence in every other case, but not this one.
Point at the derive macro attribute:
Do not provide suggestions to add type parameters which would be nonsensical when coming from a proc-macro (because they get suggested on the annontated item):
I believe this is enough to close #160463.
Follow up to #160695.