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
Seven tests across five files fail on master on both macOS and the Linux runner. Each
file has exactly one commit — the one that added the test alongside the feature it
tests — and none has been touched since:
file
added
commit subject (truncated)
verilog_r_si_1.rs
2026-05-22
wave-27: t27c gen-verilog emits __mul_noop(a, b) helper
R-SI-1 helper missing: `__mul_noop` function declaration not found.
Expected exactly 2 module-scope `_bench_<name>_cycles` counters … got [].
array-param index did not lower to a 64-bit part-select
Error: Compile error: parse error in fn 'driver' near line 8:
unexpected token after expression statement: KwReturn
The emitter code is still there
This is the part that makes it a defect rather than a cleanup. Checked on origin/master:
__mul_noop — 9 hits in bootstrap/src/compiler.rs, including the emission itself at :11842: function [63:0] __mul_noop; // t27#1886: 64-bit, u64 products no longer truncate
So the features were not removed. The emitter still knows how to emit them and no longer
reaches that path for these inputs. That is a conditional regression, not a deletion, and
it will not show up in a diff of the feature's own code.
r_ca_2 is different in kind and possibly the most interesting: it fails at parse, not
emission — unexpected token after expression statement: KwReturn. Its fixture no longer
parses at all.
Why nobody noticed
cargo test -p t27c --tests stops after the first failing target; these are targets 43–73
of 73, so they never ran. That is #2382. The ratchet landed in #2383 now runs all 73 and has
these seven baselined, so they will not regress further unnoticed — but baselining is not
fixing, and this issue is the fixing.
What is NOT established
Whether these ever passed. Each was added in the same commit as an implementation whose
message claims the feature works, which makes "passed, then regressed" the likely reading —
but I did not check out those commits and run them, so I am not asserting it.
Born-failing and regressed need different responses, and the distinction is one bisect away
for anyone who wants it.
Whether the seven share one cause. Five files, two shapes (missing emission vs parse
failure). They may be one regression or five.
Separately: four tests are baselined that CI passes
spec_first_layer2_packs_two_neuron_trits, spec_first_mlp2_…, spec_first_mlp3_… and spec_first_neuron_n_accumulates_and_quantizes fail on macOS and pass on the Linux
runner. They are in the baseline, which means a genuine Linux regression in any of them
would be invisible to the ratchet. Being pruned separately.
What
Seven tests across five files fail on
masteron both macOS and the Linux runner. Eachfile has exactly one commit — the one that added the test alongside the feature it
tests — and none has been touched since:
verilog_r_si_1.rs__mul_noop(a, b)helperverilog_initial_decl.rsverilog_translate_off.rsverilog_array_literal_expr.rsverilog_array_param_index.rsThe failing tests:
Messages:
The emitter code is still there
This is the part that makes it a defect rather than a cleanup. Checked on
origin/master:__mul_noop— 9 hits inbootstrap/src/compiler.rs, including the emission itself at:11842:function [63:0] __mul_noop; // t27#1886: 64-bit, u64 products no longer truncate_bench_— 6 hits ·translate_off— 4 hits · part-select — 9 hitsSo the features were not removed. The emitter still knows how to emit them and no longer
reaches that path for these inputs. That is a conditional regression, not a deletion, and
it will not show up in a diff of the feature's own code.
r_ca_2is different in kind and possibly the most interesting: it fails at parse, notemission —
unexpected token after expression statement: KwReturn. Its fixture no longerparses at all.
Why nobody noticed
cargo test -p t27c --testsstops after the first failing target; these are targets 43–73of 73, so they never ran. That is #2382. The ratchet landed in #2383 now runs all 73 and has
these seven baselined, so they will not regress further unnoticed — but baselining is not
fixing, and this issue is the fixing.
What is NOT established
message claims the feature works, which makes "passed, then regressed" the likely reading —
but I did not check out those commits and run them, so I am not asserting it.
Born-failing and regressed need different responses, and the distinction is one bisect away
for anyone who wants it.
failure). They may be one regression or five.
about fix(compiler): dead-store elimination deleted every write to module state (Closes #2363) #2380, which touched the optimiser today — the baseline that surfaced these was taken
after it, so it cannot distinguish.
Separately: four tests are baselined that CI passes
spec_first_layer2_packs_two_neuron_trits,spec_first_mlp2_…,spec_first_mlp3_…andspec_first_neuron_n_accumulates_and_quantizesfail on macOS and pass on the Linuxrunner. They are in the baseline, which means a genuine Linux regression in any of them
would be invisible to the ratchet. Being pruned separately.
Related: #2382, #2383, #2384.