mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-27 22:45:39 -04:00
Drew T
41a3de342d
- ROOT CAUSE PINNED, and my first hypothesis was WRONG (R14, corrected in the log): I wrote that a gate transform ate a `/*` opener and turned comment prose into code. REFUTED — cast_call_sites, sig_unify and reconcile_tu each run with the gate's real --src-file all preserve it. The real cause is family_remap's preamble backscan, whose accept-set (blank/extern/comment/typedef) HALTS AT THE FIRST `#define` and never reaches typedefs above the macro block. `_carry_macros` then re-attaches the macros, which HIDES the truncation — the unit looks complete and is not. "parse error before 'unsigned'" was that failure surfacing at the next token (the following `extern unsigned char` line): a misleading label, not a second defect. - FIX: _carry_typedefs() — additive, TRANSITIVE (a carried typedef may name another; measured: carrying Vec8_80182FD4 alone then failed on SVECTOR_8016E7C8), and BRACE-AWARE (a `;`-terminated scan stops INSIDE the struct at its first member line, emitting a truncated unclosed typedef). Emits dependency-first for C89. Only types the unit actually names and does not already carry. - VERIFIED: the 0x80182FD4 unit now carries its Prim_8016E7C8 block complete; the 0xECC family's remaps now carry the four typedefs I had prepended BY HAND before gating them — i.e. the fix automates the exact workaround that banked those three siblings. Residual isolated-compile failure on SVECTOR_8016E7C8 is a match_one artifact: that type lives in src/shared/engine_types.h, which the real TU includes — the typedef gap is fatal ONLY when the target TU lacks the type, which is why this class failed loudly for some families and silently succeeded for others.