You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The probe step reported nothing and took no time, which says the first probe
crashed and the step then died formatting its exit code. Two bugs, and the
formatting one is why the table nobody got would have named the statement:
in PowerShell 0xFFFFFFFF is Int32 -1, so the -band was a no-op, and [uint32]
threw on the very value the cast existed to display. `-f` with X8 renders a
negative Int32 as two's-complement hex by itself.
The first probe is CLS, and CLS is the one console statement whose exit code
no test checks. That is not a coincidence. compile_and_run_raw returns Ok
whatever the program did, so a crash arrives as truncated output -- and
test_cls_resets_the_column asserts that a newline does *not* appear after the
escape, which a program that died writing the escape satisfies perfectly. It
has been green on Windows throughout.
RunOutput::assert_ran_to_completion fixes the shape: it fails on any nonzero
exit and prints the code in hex, since Windows says what went wrong in it.
Every test that reads stdout for what a console statement wrote now calls it,
and a new test runs all sixteen console programs and asks only whether they
survived -- which a crash cannot fake. Verified by pointing one entry at
`PRINT 1/0`, which fails it.
The probes now split CLS by what its program links: alone it pulls in almost
nothing, while the same statement after a PRINT pulls in the whole file half
of the runtime. If one crashes and the other does not, the fault is in what
the linker kept rather than in the instructions, which is the question a
harness running the real Win64 output on Linux cannot answer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments