fix(intl): #5581 — formatRange equal endpoints use approximate form

[proggeramlug]

Summary

Follow-up to #5771 addressing a CodeRabbit correctness flag that landed after that PR merged.

Per ECMA-402 PartitionNumberRangePattern, Intl.NumberFormat.prototype.formatRange renders the approximate (~) form whenever the two endpoints format to the same string — and this includes mathematically equal endpoints. #5771 special-cased equal endpoints to a plain single value, diverging from the spec and from the Node oracle:

new Intl.NumberFormat("en-US").formatRange(3, 3)        // spec/Node: "~3"  — was "3"
new Intl.NumberFormat("en-US").formatRangeToParts(3, 3) // spec/Node: [{approximatelySign,"~",shared},{integer,"3",shared}] — omitted the sign

Change

Drop the range_endpoints_equal fast path so equal endpoints flow through the existing sx == sy approximate branch in both formatRange and formatRangeToParts.

Validation

• Output now matches node v26 byte-for-byte for formatRange(3,3) / formatRangeToParts(3,3).
• Pinned test262 corpus (intl402/NumberFormat/prototype/{formatRange,formatRangeToParts}): 16 pass / 3 fail unchanged, 0 compile failures — no test-count regression (the remaining 3 are the exact-ICU-formatting cases out of scope for fix(intl): #5581 — add Intl.NumberFormat formatRange/formatRangeToParts #5771).

Refs #5581.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Improved range formatting so identical-looking values are shown as approximate ranges rather than exact collapsed values.
  • Updated parts output to include an approximation marker when both endpoints render the same, while keeping distinct ranges clearly separated with an en dash.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 128d7a93-b4c3-43db-ae31-47712dea8c12

📥 Commits

Reviewing files that changed from the base of the PR and between 2412d05 and a6133e6.

📒 Files selected for processing (1)

• crates/perry-runtime/src/intl/number_format.rs

---

📝 Walkthrough

Walkthrough

number_format_range_value and number_format_range_parts_value in number_format.rs are updated to replace the prior numeric equality collapse with a rendered-string comparison. Both functions now render both endpoints first and emit ~{sx} / approximatelySign+shared segments when the strings match, or {sx}–{sy} / startRange+en-dash+endRange otherwise.

Intl.NumberFormat formatRange approximate collapse

Layer / File(s)	Summary
formatRange and formatRangeToParts rendered-string collapse crates/perry-runtime/src/intl/number_format.rs	Removes the early numeric-equality path from both number_format_range_value and number_format_range_parts_value; both now render both endpoints and decide between approximate (~) and en-dash range output by comparing rendered strings. Doc comments updated to match.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related issues

• test262 intl402/NumberFormat — 71 fails (formatToParts/notation/rounding/locale negotiation) #5581: This PR directly modifies Intl.NumberFormat.prototype.formatRange and formatRangeToParts collapse behavior, overlapping with the repair work described in that issue.

Possibly related PRs

• PerryTS/perry#5771: Directly precedes this PR's changes to the same number_format_range_value and number_format_range_parts_value functions in the same file.

Poem

🐇 Hop hop, the numbers meet,
Their rendered strings compared with care,
When both look equal, tilde's neat,
Otherwise a dash sits there.
No math alone decides the fate—
Just how the digits render, mate! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly states the main change: equal endpoints now use the approximate format in Intl.NumberFormat range formatting.
Description check	✅ Passed	The description covers summary, change details, related issue, and validation, matching the template well enough despite minor checklist omissions.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/5581-formatrange-approx-equal

---

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.}