gc: clean three runtime modules to zero raw-handle debt (Layer 3) - #7458
Conversation
First use of #7457's per-module ceilings, and the mechanism did its job: converting the three sites left the gate RED with array/from_concat.rs: ceiling of 1 matches nothing -- the module is clean (or gone). DELETE its line so the cleanup cannot be undone. until the lines were removed. That is rule 3 working -- without it a cleaned module keeps its allowance and silently re-permits the debt. array/from_concat.rs js_array_grow -> across_const object/array_object_ops.rs js_string_coerce -> across_mut symbol.rs gc_malloc -> across_mut Each is the canonical shape: an allocating call immediately above a re-read of a rooted receiver. Semantically identical; the ordering is now structural rather than conventional. 110 -> 107 modules, 1002 -> 999 sites. Those three can never regress: they are no longer on the list, so rule 1 holds them at zero.
|
Warning Review limit reached
Next review available in: 1 minute You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
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 |
1 participant
First use of #7457's per-module ceilings, on real work.
Three modules had exactly one bare read each, and all three were the canonical shape — an allocating call immediately above a re-read of a rooted receiver:
array/from_concat.rsjs_array_growacross_constobject/array_object_ops.rsjs_string_coerceacross_mutsymbol.rsgc_mallocacross_mutThe mechanism did its job on first contact. Converting the sites left the gate red:
That is rule 3, and it is the difference between this and a plain ratchet: a cleaned module cannot keep its allowance. Once the line is gone the module falls under rule 1, which holds it at zero — so these three cannot regress, rather than merely being 3 below a number that drifts.
110 → 107 modules, 1002 → 999 sites.
Each conversion is semantically identical (
across_mut(f)islet r = f(); (r, self.get_raw_mut_ptr())); what changes is that the ordering is structural. That is the point of #7341, where every fix in the family was an ordering bug rather than a missing root — a manual pair is exactly what drifts when someone edits between the two lines.cargo test -p perry-runtime --lib: 1712 passed / 0 failed.cargo fmt --checkclean.Of the ten single-site modules, these were the three cleanly convertible ones.
json/stringify_scalars.rs's read is an argument to the call it precedes, so it must be read first andacross_*cannot express it; the others need more restructuring than belongs in this PR.