t27c check is silent on a spec that declares the same top-level name twice

[gHashTag]

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.

[gHashTag]

Measured the gap this issue left open.

Over 582 generated translation units, counting top-level pub struct / pub enum / pub fn names that appear more than once in one file:

	count
files with a duplicated item	3
duplicated items	25
error[E0428] (defined multiple times)	37
error[E0119] (conflicting impls)	7

file	duplicated items
specs/igla/coder/benchmark.t27	13
specs/ml/optimizer/adamw.t27	11
specs/file/operations.t27	1

So the defect is dense rather than wide: three files, and two of them carry almost all of it. E0119 only appears where the duplicated item is a type whose derives then conflict; the fn duplicates surface as E0428, which is why the earlier count of 1 file understated it.

[gHashTag]

Correction: the title and the diagnosis in the body above are both wrong, and I wrote them.

AdamWConfig does not arrive through use, and use_resolve.rs is not involved. The spec declares it twice, itself:

$ grep -n 'const AdamWConfig = struct' specs/ml/optimizer/adamw.t27
28:    pub const AdamWConfig = struct {
483:    pub const AdamWConfig = struct {

My original grep missed both because it looked for struct AdamWConfig and the spec uses the Zig spelling pub 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 two AdamWConfig bodies are not identical, one ends use_phi_betas : bool and the other phi_variant : PhiVariant.

So use_resolve.rs emits 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, E0428 37 and E0119 7.

spec	duplicated items
specs/igla/coder/benchmark.t27	13
specs/ml/optimizer/adamw.t27	11
specs/file/operations.t27	1

A 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 impl blocks in files such as specs/pins/parser.t27, which is written in Rust (Vec<PinToken>, &self, Option<&PinToken>) and does not parse at all — gen-rust produces 0 bytes. A line-based matcher cannot see scope. Do not use 8/35.

The real defect

t27c check exits 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.