The 44 data-symbol conflicting-types failures are NOT the cdFileLocTable duplicate-typedef class.
They are genuine per-view type differences: D_80078EB4 is s16 at 2,409 sites and u16 at 1,341;
D_800AE620 is Blk20/s32/Mat32. For data the declared type drives the load (lh vs lhu), so
canonicalising would rewrite thousands of already-banked sites' codegen. The answer is one type
PER VIEW — the §37 asm-label alias the fleet already hand-writes for D_800AE620 (9 sites).
Shipped: scope_data_externs now auto-aliases a conflicting extern —
extern s16 aD80078EB4 __asm__("D_80078EB4");
keeping the draft's own type (byte-truth for that body) while the private C name makes collision
impossible and the asm label pins the emitted symbol, so codegen is unchanged. Fires only where
the TU declares that symbol with a DIFFERENT type text; same-type and already-aliased drafts are
untouched (4 controls, 2 of them negative). Applied on both scope paths — a staged draft's externs
arrive indented, so a demote-path-only fix reached 1 of 44.
R22 clean-fleet: check-all 213 passed / 0 failed of 213.
WHY ONLY 2 BANKED — the collision is DRAFT-vs-DRAFT, not draft-vs-TU. The failing draft declares
`extern s32 D_80114F24;` and ov_MAIN_012.c declares that symbol nowhere; the error lands at the
splice point. family_sweep stages every member of an (overlay, split) group into one TU before
gating, so two templated bodies with different views of one symbol collide with each other.
scope_data_fix sees one draft plus the pre-splice TU and structurally cannot see the others.
The real fix belongs in the staging loop, which knows the whole group: alias any data symbol
declared with >=2 distinct types across the drafts staged together. Not attempted here.
Three wrong inferences on this one task before reading a failing draft: scoped as the typedef
class; aliased only the demote path against the file's own comment; targeted the wrong collision.
Drew T
d4d35ec738