Platform becomes a real class, and its destructor says why

[andrewboudreau]

Platform becomes a real class, and its destructor says why

72 classes derive from Platform -- more than from anything but Actor itself --
and its header was still a rung-0 generated skeleton: a flat struct of u8 pad
blocks with no base, no vtable and no destructor, duplicating Actor's fields
from 0x05c down.

THE DESTRUCTOR IS THE EVIDENCE, and it closes on three boundaries at once:

t[0] = _ZTV8Platform
MovingMeshCollider::~MovingMeshCollider(this + 0x124)
Model::~Model(this + 0xd4)
Actor::~Actor(this)

Actor is 0xd0, so Platform's own data starts there. Model is 0x50, so a Model
at 0xd4 ends at exactly 0x124 -- where the destructor puts the collider.
MovingMeshCollider is 0x1c8, so it ends at 0x2ec. Three sizes, each asserted by
its own header, each landing on an offset the destructor names independently.

WHAT THE MARKERS TURNED OUT TO BE. Four of the generated fields were never
Platform's: unk_0f0 is the Model's own mat4x3 (0xd4 + 0x1c), and unk_114/118/
11c are that matrix's translation row (+0x24/+0x28/+0x2c). UpdateModelPosAndRotY
was writing the model's position through raw offsets and now says so, with the
this + 0xf0 magic address gone.

AND 0x2ec IS A SECOND MATRIX, on the same kind of arithmetic. The generated
header had 0x24 of padding there and three s32 at 0x310/0x314/0x318 -- but
0x2ec + 0x24 IS 0x310, so those three are that span's last row and 0x2ec..0x31c
is one Matrix4x3. UpdateClsnPosAndRot settles it: it copies the model's matrix
in and then writes the actor's position into 0x310/0x314/0x318. A matrix and its
translation, not four unrelated fields. It is what the mesh collider is
transformed by, so it is mClsnMat.

Also migrated: IsClsnInRange and IsClsnInRangeOnScreen (unk_0b0 was
Actor::mFlags). Five sources, three shadow structs deleted, and the two
remaining Obj/MMC stand-ins are gone entirely.

ONE IDIOM DELIBERATELY KEPT. UpdateClsnPosAndRot still casts to a flat 12-word
struct for the matrix copy. mClsnMat = mModel.mat4x3 is the readable spelling
and is +0x10 bytes: Matrix4x3 is {Matrix3x3 r; Vector3 t;}, so member-wise
assignment copies 9 words then 3 (ldm/stm 4+4+1, then a separate 3) where the
ROM copies 12 flat as 4+4+4. include/MovingMeshCollider.h already records this
obstacle for SetFile and Transform and asks for one shared flat-copy helper in
a pass of its own. This is not that pass.

The destructor is defined INLINE, per the convention this branch establishes --
all 72 subclasses inline its vptr store rather than calling it, so the body has
to be visible. Its D1 file carries the forcing TU.

GATES
build_pin.verify 5/5 (True, '2004/b56')
eligible.py 10811 -> 10811, name list IDENTICAL
rombuild -j16 106/106 exact, 0 mismatching, 10,811 source-built, 87.83%
check_header_offsets 8 commented fields, 0 mismatched, 0 unparsed, 0x31e
no --no-verify

A first eligible run reported func_ov006_020c3ad8 as "compile failed" and it is
void func_ov006_020c3ad8(void) {} with no includes -- it cannot see this
header, and it compiles standalone. Transient build contention; a serial re-run
returned an identical name list. Recorded because the reflex on a broken
neighbour should be to re-run before believing it.

Stacked on #1369, which establishes the inline-destructor convention this uses.

---

🤖 Generated with Claude Code

[tangos-validator]

✅ PR validation — Passed

Committed merge introduces no reconstruction or attribution regression.

Full merge validation

Check	Result
Committed test merge	yes
Matched functions	11,178 / 11,347 (98.5%, +0)
Matched code bytes	2,078,800 / 2,211,124 (94.0%, +0)
Tracked source enrollment	10,784 functions, 1,935,864 bytes (87.55%, +0)
Perfect source moves	0 R100
Contributor credit	0 added, 0 changed, 0 lost
Relocation check	2 checked; 2 BENIGN
Port reference check	393 checked; 0 stale
Module fidelity	106/106 exact; 100.000000% compared bytes
Code linked from verified source	10,812 functions, 1,942,752 bytes (87.86%)

Per-file link-check detail

All 1 changed file(s) compile to the ROM byte-for-byte with correct relocation targets.

File	Symbol	Result	Slots checked
src/_ZN8PlatformD1Ev.cpp	_ZN8PlatformD1Ev	✅ benign (equivalent veneer/twin)	2 (+1 passenger)

• src/_ZN8PlatformD1Ev.cpp also verified 1 emitted passenger(s): _ZN8PlatformD0Ev

_{The private worker commits a test merge, builds the stock ROM profile, compares every executable module, measures matched and source-built code, checks contributor lineage, and verifies affected relocations. The mod profile is opt-in and is not part of this merge gate.}

[andrewboudreau]

Superseded by #1374, which reconstructed Platform independently and at the same time.

The two agree on what matters — Model at 0xd4, MovingMeshCollider at 0x124, a Matrix4x3 at 0x2ec — which is decent mutual corroboration. #1374 is right where they differ: sizeof 0x324 rather than my 0x320, with 0x31e/0x320/0x322 as Platform's own fields on evidence from BowserFireSeaArena that I did not have.

#1374 also solved the flat 12-word Matrix4x3 copy properly, by including common.h first so Matrix4x3 is the flat s32 m[12] spelling. My *(M4*) cast was a workaround for not knowing that.

Closing in favour of #1374; the subclass work is rebuilt on it in #1377.

[andrewboudreau]

Rebased, and most of this PR is now on main — but the part that is left is the part I could not do.

#1374 landed the Platform class promotion while this was open: same base, same members, Matrix4x3 mClsnMat at 0x2ec, same inline ~Platform() {}. Two independent reconstructions agreeing field for field is worth more than either alone, and I would rather say that plainly than quietly drop your commit.

Resolving the rebase I took main's include/Platform.h and its UpdateClsnPosAndRot / UpdateModelPosAndRotY (already merged and byte-verified; IsClsnInRangeOnScreen was byte-identical between us). What survives is what main does not have and what I had left undone:

• src/_ZN8PlatformD1Ev.c → .cpp, a real Platform destructor, via the Platform_EmitDestructor trick to force the out-of-line copy of an inline destructor. That is a genuinely new technique in this tree and it is the whole remaining content of the PR.

The diff against #1369 is now 3 files. Rebuilt: 106/106 exact, 0 mismatching, 10,812 source-built.

One thing I dropped that you may want back: your IsClsnInRange / IsClsnInRangeOnScreen declarations in Platform.h. Both take Fix12<int> by value, so under runbook §7 they can be declarations-for-callers but never definable methods, and main's IsClsnInRangeOnScreen file defines the symbol as an extern "C" free function. I did not want to risk that interaction inside a rebase I was doing on your behalf — re-add it if you have measured it.

[andrewboudreau]

Retargeted this PR's base from cpp/inline-base-dtors to main, so that #1369 and #1370 become one merge unit.

Why: #1369 alone fails the validator (Full ROM build: mwccarm failed) and cannot merge, and because it was the base of this PR, nothing above it could merge either. But the tree that includes it builds fine — this PR's own report, when its base was cpp/inline-base-dtors, says Module fidelity 106/106 exact, code linked from verified source 10,812 functions. The worker can build main + #1369 + #1370; it cannot build main + #1369.

So the pair is viable and the single commit is not. origin/main..cpp/platform-dtors is now exactly those two commits, and this PR merging brings both. #1369 becomes redundant and will close itself when this lands.

Nothing was rewritten — same two commits, d4dbfd99 and 51bd7592. Only the base pointer moved, and it is reversible if you would rather split them again.

A caveat on my own earlier evidence, since it changes how much weight to put on it: each stacked PR validates only its own delta against its own base, so #1375's success never re-tested #1369 against main. What actually supports "the pair is fine" is the module-fidelity line in this PR's report, which is a full-ROM build of a tree containing both commits. Now that the base is main, the next run tests exactly the combination that will land.