Found during the #7708-residue fix audit. native_proof_regressions::typed_f64_receiver_method_clone_raw_loads_after_composed_guards is red on current main (0.5.1468) — deterministically, 3/3 runs — with:
the Ptr clone reached on raw-f64 guard FAILURE must coerce every slot it loads — without that it is the typed clone under another name, and a receiver whose fields are not raw f64 would take raw loads anyway
Window is exactly nine merges: the test PASSED in my post-landing audit at 82f0e9681 this afternoon (full-suite log retained) and FAILS at 079e646dd. That bounds it to #7833, #7834, #7835, #7836, #7831, #7840, #7832, #7839, #7842.
Suspect ranking: #7833 (prop_cse) first — it rewrites property reads across diverging guard chains, which is precisely the composed-guard structure this test pins, and a CSE'd read feeding the $pshape clone could legitimately change which loads need coercion — or could let a raw load through. #7842 second (it reroutes + operand typing, and the clone's slot loads feed arithmetic). The others don't touch the clone's input shape.
The safety question to answer before assuming "test needs updating": the assertion guards against the $pshape clone becoming "the typed clone under another name". If prop_cse hoisted a read ABOVE the raw-f64 guard, the clone may now receive a value whose coercion happened (or didn't) on a different path — that could be a correct-and-stronger shape (update the test, ideally to assert the property rather than the symbol per #7807's precedent in this very suite) or a genuine raw-load-without-proof (a miscompile of the #6984 family). Read the emitted IR at the fixture; do not decide from the diff.
Fourth instance today of crates/*/tests/ being invisible per-PR (#6037, #7708, the push-barrier census, now this) — it landed green within hours of #7807 fixing this exact test.
Repro: cargo test -p perry-codegen --test native_proof_regressions typed_f64_receiver_method_clone
Found during the #7708-residue fix audit.
native_proof_regressions::typed_f64_receiver_method_clone_raw_loads_after_composed_guardsis red on current main (0.5.1468) — deterministically, 3/3 runs — with:Window is exactly nine merges: the test PASSED in my post-landing audit at
82f0e9681this afternoon (full-suite log retained) and FAILS at079e646dd. That bounds it to #7833, #7834, #7835, #7836, #7831, #7840, #7832, #7839, #7842.Suspect ranking: #7833 (prop_cse) first — it rewrites property reads across diverging guard chains, which is precisely the composed-guard structure this test pins, and a CSE'd read feeding the
$pshapeclone could legitimately change which loads need coercion — or could let a raw load through. #7842 second (it reroutes+operand typing, and the clone's slot loads feed arithmetic). The others don't touch the clone's input shape.The safety question to answer before assuming "test needs updating": the assertion guards against the
$pshapeclone becoming "the typed clone under another name". If prop_cse hoisted a read ABOVE the raw-f64 guard, the clone may now receive a value whose coercion happened (or didn't) on a different path — that could be a correct-and-stronger shape (update the test, ideally to assert the property rather than the symbol per #7807's precedent in this very suite) or a genuine raw-load-without-proof (a miscompile of the #6984 family). Read the emitted IR at the fixture; do not decide from the diff.Fourth instance today of
crates/*/tests/being invisible per-PR (#6037, #7708, the push-barrier census, now this) — it landed green within hours of #7807 fixing this exact test.Repro:
cargo test -p perry-codegen --test native_proof_regressions typed_f64_receiver_method_clone