Rustc incorrectly suggests adding generic arguments to an enum that already has them when using enum-map-derive =1.0.0

@estebank

Code

#[derive(enum_map_derive::Enum)]
enum ExampleEnum<T> {
    Variant(T),
}

Current output

Checking enum-generic-repro v0.1.0 (/Users/centdemeern1/Documents/RustProjects/enum-generic-repro)
error[E0425]: cannot find type `T` in this scope
 --> src/lib.rs:3:13
  |
3 |     Variant(T),
  |             ^ not found in this scope

error[E0107]: missing generics for enum `ExampleEnum`
 --> src/lib.rs:2:6
  |
2 | enum ExampleEnum<T> {
  |      ^^^^^^^^^^^ expected 1 generic argument
  |
note: enum defined here, with 1 generic parameter: `T`
 --> src/lib.rs:2:6
  |
2 | enum ExampleEnum<T> {
  |      ^^^^^^^^^^^ -
help: add missing generic argument
  |
2 | enum ExampleEnum<T><T> {
  |                 +++

Some errors have detailed explanations: E0107, E0425.
For more information about an error, try `rustc --explain E0107`.
error: could not compile `enum-generic-repro` (lib) due to 2 previous errors

Desired output

Rationale and extra context

rustc should probably not be suggesting invalid syntax. I don't know what this error should look like instead, though

Other cases

Rust Version

rustc 1.97.1 (8bab26f4f 2026-07-14)
binary: rustc
commit-hash: 8bab26f4f68e0e26f0bb7960be334d5b520ea452
commit-date: 2026-07-14
host: aarch64-apple-darwin
release: 1.97.1
LLVM version: 22.1.6

Anything else?

enum-map-derive does not actually support generic arguments. The latest version of enum-map-derive adds a manual check, which bypasses this bug. To reproduce this bug, use =1.0.0
I was told to report this by @estebank: https://hachyderm.io/@ekuber/117031928263200472
Here's a repro project that uses the correct version of enum-map(-derive): enum-generic-repro.zip

The crate specific problem was fixed at https://codeberg.org/sugar700/enum-map/pulls/191, by explicitly rejecting items with generics.

I suspect that E0107 is missing a check for whether the span we're pointing has a macro context corresponding to a derive. The fact that the error doesn't already have a "within this derive" makes me concerned that we're not properly keeping the span context around in some way.

This is first of all a small bug on the crate, but rustc must handle improperly built derive crates gracefully as much as possible.

The token for type name doesn't come from a macro. enum_map generates code like this

impl ::enum_map::Enum for #name {
     // ...
}

where name comes from input, pasting the TokenStream representing the type name (without generics) directly.

@petrochenkov

I can confirm that by passing the token straight through the span doesn't get a context (it is #0) 😵

 INFO rustc_hir_analysis::hir_ty_lowering::generics seg.ident.span=src/main.rs:6:6: 6:17 (#0)
error[E0107]: missing generics for enum `ExampleEnum`
 --> src/main.rs:6:6
  |
6 | enum ExampleEnum<T> {
  |      ^^^^^^^^^^^ expected 1 generic argument
  |
note: enum defined here, with 1 generic parameter: `T`
 --> src/main.rs:6:6
  |
6 | enum ExampleEnum<T> {
  |      ^^^^^^^^^^^ -
help: add missing generic argument
  |
6 | enum ExampleEnum<T><T> {
  |                 +++

This seems... quite wrong. I can likely fix this in this error, but we should absolutely be fixing our macro machinery.

CC @petrochenkov is this the expected behavior? I would have figured that any token coming from a proc-macro would automatically get tagged with a span context, but it doesn't seem to be the case. Doesn't this cause lots of trouble with hygiene?

CC @petrochenkov is this the expected behavior? I would have figured that any token coming from a proc-macro would automatically get tagged with a span context, but it doesn't seem to be the case. Doesn't this cause lots of trouble with hygiene?

Procedural macros are free to assign any spans to tokens they emit, including spans literally copied from the macro inputs.
If the span is copied from the macro input, then it won't have any traces of the macro in it.

@petrochenkov

@petrochenkov thanks for the confirmation that this is intentional.

It is not ideal, as I'd like to have some marker for things coming from a derive (as we already rely on the span context to enhance diagnostics making them easier to understand in a generic way that works with every diagnostic). Would it be reasonable to introduce a "transparent context" for these tokens? Something that for all intents and purposes is its parent context for nameres. I recall experimenting with doing that for synthetic spans built from parts of other spans and recall it being a >5% regression. I can of course deal with this on this specific diagnostic, but others will prop up if we don't have something more generic, I'm sure.

My reasoning is that although crate authors should be aware of foot-guns like these ones, rustc should still gracefully handle crates that aren't written to the high levels of quality and care that we'd want.

I need to fully clean this up so that the output looks as expected, but I have a preliminary implementation of a fix in https://github.com/rust-lang/rust/compare/main...estebank:rust:issue-160463?expand=1

After #160695, the only thing left would be to figure out if we can silence the nameres error from smart_resolve_report_errors, but that might be too difficult to accomplish (in a sane way).

Rollup merge of rust-lang#160695 - estebank:issue-160463, r=petrochenkov

Unrolled build for #160695 in rollup 163363

Rollup merge of rust-lang#163380 - estebank:issue-160463-2, r=TaKO8Ki

Unrolled build for #163380 in rollup 164005

Rollup merge of #163380 - estebank:issue-160463-2, r=TaKO8Ki

Navigation Menu

Repository navigation

Rustc incorrectly suggests adding generic arguments to an enum that already has them when using enum-map-derive =1.0.0 #160463

Code

Current output

Desired output

Rationale and extra context

Other cases

Rust Version

Anything else?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Rustc incorrectly suggests adding generic arguments to an enum that already has them when using enum-map-derive =1.0.0 #160463

Description

Code

Current output

Desired output

Rationale and extra context

Other cases

Rust Version

Anything else?

Activity

estebank commented on Aug 3, 2026

sugar700 commented on Aug 4, 2026

estebank commented on Aug 5, 2026

petrochenkov commented on Aug 5, 2026

estebank commented on Aug 6, 2026

estebank commented on Aug 6, 2026

estebank commented on Sep 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions