test(hir): pin the for-of desugar counter's literal kind at both emission sites (#7766 follow-up) - #7790
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdds lowered-HIR tests for synthetic ChangesFor-of counter validation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…sion sites (#7766 follow-up) #7778 made both for-of desugar sites mint the synthetic __idx_* counter as Expr::Integer(0) — the literal kind collect_integer_let_ids seeds on, and thus the difference between a counter that gets a canonical i32 slot and one that is invisible to every i32-counter loop optimization. Nothing pinned it: the desugar is correct either way and prints identical output, so a revert to Number(0.0) would silently un-optimize every for-of loop with no test failing. Verdict tests on the lowered HIR, one per emission site (module-init and function-body have drifted independently before), both sabotage-verified.
9137ec0 to
2f62c3e
Compare
|
Audit complete — merging.
This closes the coverage gap named in #7778's merge audit: the |
Follow-up to #7778 (which closed #7766). Tests only — no behaviour change.
#7778 changed both
for…ofdesugar sites to mint the synthetic__idx_*counter asExpr::Integer(0)instead ofExpr::Number(0.0). That literal kind is whatcollectors/i32_locals.rs::collect_integer_let_idsseeds on — it does not reason about provable integrality — so it is the difference between a counter that gets a canonical i32 slot and one that is structurally invisible to every i32-counter loop optimization. #7771's element-binding element-shape clone is the case that made it visible: its matcher hard-requiresctx.i32_counter_slots, so before the fix it could not fire forfor…ofat all (measured: 0.83s → 0.09s on a 200k-element parameter-array loop).Nothing pins it. The desugar is correct either way and prints identical output, so an edit back to
Number(0.0)would silently un-optimize everyfor…ofloop in the language with no test failing — CLAUDE.md's fourth way a gate can be unable to fail ("the gate runs but its subject never did").These are verdict tests on the lowered HIR, one per emission site —
lower/stmt_loops.rs(module init) andlower_decl/body_stmt.rs(function bodies), which have drifted independently before. Both are sabotage-verified: reverting either site toNumber(0.0)reds them.for-in is deliberately not covered: its counter indexes a keys array rather than the receiver, and #7778 left it alone.
Summary by CodeRabbit
Bug Fixes
for…ofloops, helping ensure loop counters are initialized consistently and retain optimized integer behavior.Documentation
for…ofcounter behavior and its optimization expectations.Chores
0.5.1459.