Repository navigation
t27c check is silent on a spec that declares the same top-level name twice #3438
Description
What
specs/ml/optimizer/adamw.t27 does not declare AdamWConfig:
$ grep -c 'struct AdamWConfig' specs/ml/optimizer/adamw.t27
0
but the generated Rust declares it twice:
$ t27c gen-rust specs/ml/optimizer/adamw.t27 | grep -c 'pub struct AdamWConfig'
2
so the module cannot compile:
error[E0119]: conflicting implementations of trait `Debug` for type `AdamWConfig`
--> :119:10
|
25 | #[derive(Debug, Clone, Copy)]
| ----- first implementation here
...
119 | #[derive(Debug, Clone, Copy)]
The type arrives through the spec's use list:
use base::types;
use math::constants;
use numeric::gf16;
Three structs are affected in this file -- AdamWConfig, AdamWState,
OptimizerStepResult -- one E0119 per derived trait per duplicate.
Why it is worth a separate issue
The error count moves with unrelated work. Adding a third derived trait to
these structs raised E0119 from 6 to 7 while fixing #3436, which looked like
a regression in that change and is not one -- the file fails to compile either
way. A duplicate emission that inflates counts on someone else's diff is worth
removing on its own.
Where to look
bootstrap/src/use_resolve.rs. by_origin groups candidates and the emitter
takes distinct[0]; #3411 made that choice deterministic but did not ask
whether a name can reach the output through two paths at once.
Not yet measured
How many specs carry a duplicate declaration. E0119 appears in 1 file today,
but that only counts duplicates whose derives conflict -- a duplicated fn
would surface as E0428 instead, and that has not been separated.
Activity
gHashTag commentedon Sep 8, 2026
Measured the gap this issue left open.
Over 582 generated translation units, counting top-level
pub struct/pub enum/pub fnnames that appear more than once in one file:error[E0428](defined multiple times)error[E0119](conflicting impls)specs/igla/coder/benchmark.t27specs/ml/optimizer/adamw.t27specs/file/operations.t27So the defect is dense rather than wide: three files, and two of them carry almost all of it.
E0119only appears where the duplicated item is a type whose derives then conflict; thefnduplicates surface asE0428, which is why the earlier count of 1 file understated it.[-]gen-rust: a type pulled in through `use` is emitted twice[/-][+]t27c check is silent on a spec that declares the same top-level name twice[/+]gHashTag commentedon Sep 8, 2026
Correction: the title and the diagnosis in the body above are both wrong, and I wrote them.
AdamWConfigdoes not arrive throughuse, anduse_resolve.rsis not involved. The spec declares it twice, itself:My original grep missed both because it looked for
struct AdamWConfigand the spec uses the Zig spellingpub const Name = struct { … }. Finding zero matches, I concluded the name must be imported. It is not: the file is 1019 lines and carries what looks like a revised second copy of its own declarations — the twoAdamWConfigbodies are not identical, one endsuse_phi_betas : booland the otherphi_variant : PhiVariant.So
use_resolve.rsemits nothing twice. The compiler is right and the spec is wrong — the fourth time in this campaign, after #3420, #3422 and #3428.What the population actually is
The output-based figure in my earlier comment stands, because it was measured from the emitted Rust: 3 specs, 25 duplicated top-level items,
E042837 andE01197.specs/igla/coder/benchmark.t27specs/ml/optimizer/adamw.t27specs/file/operations.t27A source-side matcher I wrote while checking this said 8 specs, 35 names. Five of those eight are its own false positives: they are methods inside
implblocks in files such asspecs/pins/parser.t27, which is written in Rust (Vec<PinToken>,&self,Option<&PinToken>) and does not parse at all —gen-rustproduces 0 bytes. A line-based matcher cannot see scope. Do not use 8/35.The real defect
t27c checkexits 0 on all of them. Nothing refuses, or even mentions, a spec that declares the same top-level name twice, and the consequence is a crate that cannot compile.There is a neighbouring guard,
tools/check_duplicate_agreement.py, but it asks a different question: whether the same function name defined in different specs still computes the same thing. Same-file duplication is uncovered.The detection has to come from the compiler's own AST, not a regex, for exactly the reason the 8/35 count is wrong.
check: report a top-level name declared twice (#3439)
specs: rename the duplicated test names instead of deleting them (#3484)