fix(gc-check): recognise js_url_coerce_string as a heap-value source

[proggeramlug]

Closes the detector gap that let #7453 through.

ALLOC_RE classifies fresh-heap-value producers by naming convention. The runtime has exactly three coerce -> *mut StringHeader helpers:

helper	matched before?
js_string_coerce	yes — string_coerce
js_jsvalue_to_string_coerce	yes — jsvalue_to_string\w*
js_url_coerce_string	no — reads url_coerce_string after the js_ prefix

So a raw StringHeader pointer returned by the URL coercion was invisible to the checker, which is why #7453 had to be found by reading code rather than by the gate.

Measured, not extrapolated

The list carries an explicit warning about patterns added by extrapolating a suffix and then matching nothing. So:

• The symbol was verified to exist first — crates/perry-runtime/src/url/mod.rs:116.
• The new pattern matches what it should and not what it shouldn't: js_url_coerce_string → matches; js_string_coerce → still matches; js_url_get_href → does not.
• The new hit is the bug. On the pre-fix(codegen): root the URL constructor's coerced string across base lowering (Layer 1) #7453 IR, stale-register uses go 3 → 4, and the added one is:

url_root_ts.ll::main
  source (alloc): %r23 = call i64 @js_url_coerce_string(double %r22)
  stale use     : %r26 = call i64 @js_url_new_with_base(i64 %r23, i64 %r25)
  between       : js_url_coerce_string, perry_fn_url_root_ts__mk
  MOVING        : YES via perry_fn_url_root_ts__mk

MOVING: YES. That is worth recording: I described #7453 as latent in its PR, and the checker's own classification is stronger than that — the stale use is reachable from a moving minor via a user call.

• The gate does not move. Over the 144-module corpus both gated arms stay at 0 violations, --seeded-violations still reports 40 planted / 40 caught / 0 MISSED, and --self-test passes. The widening is additive: no previously reported source changes kind.

Stacked on #7452 (which restored the corpus) and #7453 (the bug itself).

[coderabbitai]

Warning

Review limit reached

@proggeramlug, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 3 minutes

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: fe287ca6-5dfe-472d-92ba-a41af43e108f

📥 Commits

Reviewing files that changed from the base of the PR and between 0dbdd2f and 43ea14f.

📒 Files selected for processing (2)

• changelog.d/7454-dominance-url-coerce-source.md
• scripts/gc_root_dominance_check.py

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}