Files
BFM-decomp/tools
Drew T 8479c4491e fix(phase-29): scope_data_externs DROPS a data extern the TU already declares (SC07 type-identity blocker)
THE BLOCKER: the SC07 quartet (ov_SC07_006/007/010/011) refused two families with
`conflicting types for D_800AF634`. Both sides read `S_AF634 []` — the SAME type STRING — so it is a
type-IDENTITY collision: the templated body carries its OWN block-scope `typedef struct {…} S_AF634;`
while the TU's declaration of D_800AF634 comes from a MACRO-INJECTED one (§8c), making two DISTINCT
types with one name. cdecl.compatible cannot see this and correctly answers "compatible".

THE FIX: if the TU already declares the symbol above the insertion point, DROP ours instead of
keeping it. A redeclaration we do not emit cannot collide — with anything, identity or type — and the
TU's own declaration is in scope and authoritative. Strictly better than the previous behaviour,
which was a hard compile error; the whole-binary byte-gate still arbitrates if the TU's type implies
a different access.

AND IT HAD TO REACH BLOCK SCOPE, not just column 0. §8d demotes these externs on the way in, so by
the time a sibling draft is STAGED they are already indented — a col-0-only scan (my first cut) saw
nothing to do on exactly the drafts that needed it. C requires a block-scope `extern` to agree with a
file-scope declaration in scope, so a redundant redeclaration conflicts at ANY scope.

VERIFIED on the failing member: D_800AF634's declaration is removed from the staged draft, and the
re-sweep's error moved past it. HONEST STATUS: the quartet is NOT yet banked — the next conflict is a
FUNCTION decl (`conflicting types for func_80024054`), a different axis (§58c / cast_call_sites)
which the sweep's member staging does not currently run. Not peeled further here: §95's law says
splice once and dump EVERY cc1 error rather than one per gate cycle. Tree clean, nothing banked.
2026-07-27 22:52:48 -06:00
..