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
{{ message }}
Repository navigation
Add a compile-and-run runtime scoreboard for the passing suite #93
Part of #74 (Phase 1). The M7 gate has no measurement at all: no harness compiles and runs a corpus passing file. Execution evidence today is vertical tests over inline fixtures.
Do
Add a runtime scoreboard that, per passing file, compiles to a component and runs it under Wasmtime, asserting the observable result.
Design constraints, learned from the existing harnesses
crates/psrs-driver/src/tests/mod.rs:25run_with_wasmtime compiles one module and runs wasmtime run. run_with_wasmtime_args (:56) passes argv, run_with_wasmtime_stdin (:62) feeds stdin, and run_wasmtime_with_dirs (:72) adds --dir host::guest preopens. The corpus needs all three: get-arguments, stdin reads, and preopens.
There is a duplicate private run_program_with_wasmtime at crates/psrs-driver/src/tests/integration.rs:237 that shadows the one in mod.rs and, unlike it, has no PSRS_REQUIRE_WASMTIME handling. Consolidate; a shadowed helper that silently skips is exactly the failure mode issue Add a required Wasmtime execution test gate that cannot silently skip #9 was filed to prevent.
The harness must be #[ignore]d and skip cleanly without wasmtime, and must panic under PSRS_REQUIRE_WASMTIME=1 so CI cannot let it silently pass.
Reading the expected result
Most passing files either print through Effect.Console or return a value from main as the exit code. Both are observable. Files that assert with Test.Assert fail by exit code. Decide and record how a file with no observable output is scored — as "compiles, validates, runs" rather than agreement.
Report honestly
Per-file pass/fail with the failure reason. Expect the first run to be near zero, because of Phase 2 and Phase 3. That number is the point: it is the honest L6/M7 baseline, and every later backend improvement is measured against it.
Acceptance
A runtime scoreboard reports per-file compile/validate/run agreement for all 413 non-FFI passing files, and the D-04 L6/M7 row carries the number.
Landed in #107. The gate now has a number, and the number is 0/413 — which is the point of the issue.
Measured baseline: 0 of 413 non-FFI passing files compile, validate, and run (26 excluded as FFI), reported per file by runtime::l6_runtime_scoreboard.
First blocking stage
Cases
P3 resolve
233, of which 229 stop on a missing module
P2 surface lowering
134
P10 Wasm structuring
41 (a support module with no main to select)
P0 lex
4 (the DEC-16 lone-surrogate cases)
P5 kind check
1
How agreement is defined, and why. The corpus vendors no execution goldens and upstream's passing suite is a compile-time suite, so a file agrees when the pipeline compiles it, the component passes Wasm validation, and the guest runs to completion without trapping. main's return value is recorded as the exit code and stdout is captured rather than compared, so main = 42 agrees with exit code 42. A trap or a hang fails, and a Test.Assert failure has to reach the guest as a trap to be visible at all.
The design constraints in the issue, resolved:
The duplicate private run_program_with_wasmtime in tests/integration.rs is deleted. It shadowed the shared helper and had no PSRS_REQUIRE_WASMTIME handling. Every execution helper now goes through one wasmtime_available check that also verifies wasmtime --version succeeds.
The runner takes no argv, stdin, or preopens, because no corpus case needs them: rg over tests/upstream/passing finds no get-arguments, no stdin read, and no filesystem use. That part of the issue's premise does not hold for the vendored v0.15.16 corpus, so no harness path was built for it.
The board skips cleanly without wasmtime and panics under PSRS_REQUIRE_WASMTIME=1.
A case still running at 10s is killed and reported as a hang, so one non-terminating program cannot stall the board. stdout/stderr go to files rather than pipes, so a chatty program cannot deadlock it either.
Before it measures anything the board compiles and runs main = 42 through the same path and asserts exit code 42: a board that reports zero because its runner is broken is worse than no board. The outcome classifier is a pure function with six unit tests, so all three shapes are covered without a trapping program.
Two corrections to the issue's premises.stdlib/lib is already on the scoreboard module path through compile_program_sources_with_prelude, so the remaining library gap is #94/#95, not a harness change. And 13 of the 229 missing-module rejections name a sibling corpus module the loader does not read — M1, A, B, M2, M3, Foo, Coercible.Lib2 — which is exactly #83's defect 1, so the honest library-blocked count is 216 and the board prints the missing module names to keep the two categories apart until #83 splits them.
Evidence: cargo fmt --all --check; cargo clippy --workspace --all-targets -- -D warnings; PSRS_REQUIRE_WASMTIME=1 cargo test --workspace (975 passed, 0 failed, 0 skipped); CI green on #107.
Activity
biuld commentedon Oct 1, 2026
Landed in #107. The gate now has a number, and the number is 0/413 — which is the point of the issue.
Measured baseline: 0 of 413 non-FFI
passingfiles compile, validate, and run (26 excluded as FFI), reported per file byruntime::l6_runtime_scoreboard.mainto select)How agreement is defined, and why. The corpus vendors no execution goldens and upstream's
passingsuite is a compile-time suite, so a file agrees when the pipeline compiles it, the component passes Wasm validation, and the guest runs to completion without trapping.main's return value is recorded as the exit code and stdout is captured rather than compared, somain = 42agrees with exit code 42. A trap or a hang fails, and aTest.Assertfailure has to reach the guest as a trap to be visible at all.The design constraints in the issue, resolved:
run_program_with_wasmtimeintests/integration.rsis deleted. It shadowed the shared helper and had noPSRS_REQUIRE_WASMTIMEhandling. Every execution helper now goes through onewasmtime_availablecheck that also verifieswasmtime --versionsucceeds.rgovertests/upstream/passingfinds noget-arguments, no stdin read, and no filesystem use. That part of the issue's premise does not hold for the vendoredv0.15.16corpus, so no harness path was built for it.wasmtimeand panics underPSRS_REQUIRE_WASMTIME=1.main = 42through the same path and asserts exit code 42: a board that reports zero because its runner is broken is worse than no board. The outcome classifier is a pure function with six unit tests, so all three shapes are covered without a trapping program.Two corrections to the issue's premises.
stdlib/libis already on the scoreboard module path throughcompile_program_sources_with_prelude, so the remaining library gap is #94/#95, not a harness change. And 13 of the 229 missing-module rejections name a sibling corpus module the loader does not read —M1,A,B,M2,M3,Foo,Coercible.Lib2— which is exactly #83's defect 1, so the honest library-blocked count is 216 and the board prints the missing module names to keep the two categories apart until #83 splits them.Evidence:
cargo fmt --all --check;cargo clippy --workspace --all-targets -- -D warnings;PSRS_REQUIRE_WASMTIME=1 cargo test --workspace(975 passed, 0 failed, 0 skipped); CI green on #107.