← board

Pinned stable reads LIVE builtin RTL source — track A WIP breaks track B

Symptom

Every track-B compile against the pinned stable (v9) died with:

pascal26:497: error: unexpected character ()

...including a 2-line hello world with no uses. The v9 binary is intact (sha256 matches last.sha256). The cause was an uncommitted, mid-edit compiler/builtin/builtinheap.pas in track A's lane (interface-refcounting work) — temporarily not syntactically valid.

Root cause — the isolation hole

The pinned binary is not self-contained. At runtime it does an implicit uses builtinheap and reads compiler/builtin/builtinheap.pas from the live working tree. Proof:

$ (cd /tmp && /path/to/pinned hello.pas out)
pascal26:2: error: uses: unit source not found: builtinheap ()

So the builtin RTL source is shared ground even though the binary is pinned. devdocs/dev/parallel-tracks.md claims "a half-built compiler in the tree does not block B because B uses $(PXX_STABLE)" — that is false for runtime-read RTL like builtinheap.pas (and any other source the stable resolves live).

Fix — freeze the runtime-read sources with the binary

On make pin, snapshot the builtin RTL sources next to the pinned binary and make the pinned binary resolve them from there, not the live tree:

Then B's ground is genuinely frozen until a deliberate make pin.

Interim protocol (until the fix lands)

Grey-area shared files (the builtin RTL) are a halt-and-wait zone: if compiler/builtin/** shows uncommitted edits, the other agent stops and waits rather than working around or stomping. Safer to halt than to make a mess. (Kept deliberately simple — no heavier protocol.)

Log