fix(decomp): ov_SC07_010 baseline back to green — one stale (void) decl no-proto'd

The S59 scoped R22 sweep (96 binaries whose TUs instantiate the DEFINE macros
my engine_core edit touched) found ov_SC07_010 RED at HEAD: the 14:57
maintenance commit (commit:2694) banked func_8017F2BC's (s16*) definition into a
TU that still carries an earlier draft-preamble decl 'extern void
func_8017F2BC(void);' at line 4932 — conflicting types, TU uncompilable, though
the TU is byte-identical to its committed state (how that pass reported green
is an open question for the lane's arity/splice ordering). Provenance checked:
my commits touch only func_80162CCC decls; the pinned cc1 accepts the
no-proto+definition pair in isolation. Fix: the arity pass's own byte-neutral
no-proto form; whole-binary SHA re-checked green. ov_SC07_002 remains RED on a
jtbl_rodata_pads carve drift (also pre-existing, also from earlier passes) —
named in docs/tool-designs/aprop-lane-s59.md, not papered over.
This commit is contained in:
Drew T
2026-08-24 23:03:34 -06:00
parent 488e009bd1
commit 2364da4afd
+1 -1
View File
@@ -4929,7 +4929,7 @@ INCLUDE_ASM("asm/ov_SC07_010/nonmatchings/ov_SC07_010_jr_8017AE2C", func_8017F1C
extern s32 func_8012AD50(void*);
extern void func_8017DCB8(s32 a0);
extern void func_8017F2BC(void);
extern void func_8017F2BC();
void func_8017F214(s32 a0) {
u8 *s0;