← board

What should pxx --selfcheck assert?

Raised by frankH, 2026-09-02, working feature-toolchain-cli-ux (oldest actionable). Nothing is blocked on the answer — I took the next ticket.

Why it is a fork and not a measurement

Measured: --version, --where, --list-targets, --list-libraries and --doctor all answer and exit 0; --selfcheck is unknown option. Its blocker feature-release-packaging is in done/. The compiler spawns no process (no PalVforkAndExec / PalFork anywhere under compiler/) and knows only ExeDir. tools/selfcheck.sh (46 lines) implements both checks already and is shipped inside the unpacked release, beside compiler/ and MANIFEST.sha256.

What cannot be measured is which promise the flag should make.

The options

(a) In-process double compile — compile compiler.pas twice, cmp. Tests determinism of this binary. Not a fixedpoint step, so it would not catch a binary that builds a different compiler which then diverges.

(b) Compile and compare to the running binary — a genuine fixedpoint claim and no subprocess. But it reports FAIL on any release binary built with non-default flags, where the difference is legitimate. A check that cries wolf on a correct install is worse than none.

(c) Give the compiler spawn capability and do exactly what the spec says. Faithful, and the only option whose name matches its assertion — at the cost of a new capability in the compiler binary, used by one diagnostic flag.

(d) Do not add the flag; close the item and point --help at tools/selfcheck.sh. The "flag, not a script" principle in feature-toolchain-cli-ux exists to avoid "a litter of helper scripts that confuse users" — but this is one documented script that ships inside the release tree, and it can exec, so it already does the strong check.

Recommendation: (d), with (c) as the answer if the principle is the point. (a) and (b) both put a weaker or noisier assertion behind a name people will trust, which is the failure this repo already has names for — a guard that cannot fail, and the name not being the thing. If the flag is wanted for its own sake, (c) is the only honest way to build it.

If (d): feature-toolchain-cli-ux closes, and --help gains one line.