Temporal: a difference past a calendar's range raises RangeError instead of spinning (#3452)

[lahma]

Backport of #3452 to 4.x. Fixes #3428 there too — the defect predates every released 4.x, and the hang
reproduces on this branch with the same shape and the same failure count as on main.

What was wrong

NonIsoCalendars.CalendarDateUntil measures a difference by walking one month at a time from the source
towards the target, and its only exit is "this step passed the target". NonIsoCalendars.CalendarDateAdd
takes those steps, and when the conversion back to ISO left the range of the backing
System.Globalization.Calendar it did not report that — it answered with ClampToCalendarRange, which
ignored its year, month and day arguments entirely and returned cal.MaxSupportedDateTime:

private static IsoDate ClampToCalendarRange(Calendar cal, int year, int month, int day)
{
    var dt = cal.MaxSupportedDateTime;
    return new IsoDate(dt.Year, dt.Month, dt.Day);
}

The calendar's maximum, whichever end had been overrun. So every further step of a backwards walk landed
on that same date, no step ever passed the target, and the loop had no other exit.

Temporal.PlainDate.from('1910-01-01').withCalendar('chinese')
    .until(Temporal.PlainDate.from('1900-01-03').withCalendar('chinese'), { largestUnit: 'year' });
// never returned

ChineseLunisolarCalendar spans ISO 1901-02-19 to 2101-01-28, so the target is outside it.

What an embedder saw is the thread, and nothing else. It is a CLR loop inside one interpreter step, so
it crosses no statement boundary: LimitStatements never counted, LimitExecutionTime never got a check,
and a CancellationToken was never observed. A host that bounded untrusted script the documented way still
lost the thread, and the only way back was to end the process. Reachable from any script that can name a
chinese, dangi, hebrew or persian date, through until, since and total on PlainDate,
PlainDateTime, PlainYearMonth, ZonedDateTime and Duration.

The same clamp was also answering, rather than hanging, on the addition side — with the wrong date, and with
no signal that it was wrong. Measured on unfixed 4.x:

Temporal.PlainDate.from('1950-01-01').withCalendar('chinese').subtract({ years: 100 });
// 2101-01-28[u-ca=chinese]   -- subtracting a century moved it a century and a half forward
Temporal.PlainDate.from('2050-01-01').withCalendar('dangi').add({ years: 100 });
// 2051-02-10[u-ca=dangi]
Temporal.PlainDate.from('2050-01-01').withCalendar('hebrew').add({ years: 500 });
// 2239-09-29[u-ca=hebrew]
Temporal.PlainDate.from('0700-01-01').withCalendar('persian').subtract({ years: 200 });
// 9999-12-31[u-ca=persian]

What changed

Identical in substance to #3452. Out-of-range calendar arithmetic reports itself instead of clamping.
NonISODateAdd is implementation-defined and is declared as returning "either a normal completion
containing an ISO Date Record or a throw completion"
(spec), and CalendarDateAdd raises a
RangeError for a result it cannot represent
(spec). Both overflow modes report it:
leaving the calendar's range is not the month-or-day overflow constrain is allowed to clamp, because there
is no nearby valid date to clamp to — only the calendar's own boundary.

• NonIsoCalendars.CalendarDateAdd — ClampToCalendarRange is gone; the ArgumentOutOfRangeException
  from cal.ToDateTime becomes a CalendarRangeException.
• NonIsoCalendars.IndianCalendarDateAdd and IslamicTabularCalendarDateAdd — both answered
  result ?? isoDate, handing back their input date when the conversion failed. That is the same
  no-progress answer by a different route: add reports that adding a year changed nothing, and the walk
  takes the same step forever. Both now report instead.
• NonIsoCalendars.CalendarDateUntil — the walk keeps a no-progress guard of its own. With the three fixes
  above it is unreachable today; it stays as the structural guarantee that this loop terminates, so a clamp
  reintroduced anywhere below it cannot become a hang again.
• TemporalHelpers.CalendarDateAdd / CalendarDateUntil map it to Throw.RangeError. realm is threaded
  through DifferenceISODateTime and is now required on CalendarDateUntil, so no call site can lose it
  and turn a script-visible RangeError into a CLR exception escaping Engine.Evaluate.

All internal; no public API change.

Divergence from the main PR

Three adaptations, all mechanical, and none of them changes what the fix does:

• ThrowCalendarArithmeticUnavailable does not exist on 4.x. It arrived on main in separate work,
  and Temporal: a month difference past the calendar's range raises RangeError instead of spinning #3452 merely added a sibling beside it. That hunk is dropped: 4.x keeps its
  throw new NotSupportedException($"Calendar '{calendar}' not yet supported") for a calendar with no
  arithmetic, and only ThrowCalendarRange is added. using System.Diagnostics.CodeAnalysis; had to come
  with it for the [DoesNotReturn], which main already had a use for in that file.
• CalendarDateUntil had no realm parameter at all on 4.x. On main it was already there as
  Realm? realm = null and Temporal: a month difference past the calendar's range raises RangeError instead of spinning #3452 only made it required; here it is added, required, and threaded through
  the three call sites that lacked it — PlainDatePrototype.DifferenceTemporalPlainDate and
  PlainYearMonthPrototype.DifferenceYearMonth (both pass _realm), and the week arm of
  RoundRelativeDuration in TemporalHelpers (which already held a realm). Every one had a realm at
  hand, so nothing had to be widened to carry one.
• Jint.Tests is xUnit v3 on 4.x. [Test] → [Fact], [TestCase(…, TestName: …)] → [Theory] +
  [InlineData] (the case names move into the doc comment, since InlineData has nowhere to put them),
  and DedicatedThread's join timeout keeps throwing XunitException rather than NUnit's
  AssertionException.

NonIsoCalendars.cs is still one file on this branch — the NonIsoCalendars.Lunisolar.cs split is later
main work, after #3452 — so all four engine hunks in it applied unchanged, and the two NonIsoCalendars
entry points #3452 wraps are still the only two callers in the assembly here.

Jint.Tests/DedicatedThread.cs also carries #3452's second half: a body starts at normal priority and is
demoted to ThreadPriority.Lowest only once its join has timed out, at which point it is known to be a
runaway that must be kept off the cores the rest of the run needs. Starting every body at Lowest cost a
0.1 ms evaluation 2.5 s under two competitors on main's measurement, which is what made the net472 CI
leg red there. 4.x has the same helper and the same starting priority, so it inherits the same fix.

Failing-test evidence, per target framework

Jint.Tests/Runtime/NonIsoCalendarRangeTests.cs runs every case on a dedicated thread with a 15-second
join, so a regression fails the run rather than wedging it. Against the unfixed 4.x engine (this
branch with Jint/ reverted, test file and DedicatedThread change in place):

	net472 (the net462 asset)	net10.0
before	Failed: 15, Passed: 7, Total: 22 — 2 m 15 s	Failed: 15, Passed: 7, Total: 22 — 2 m 15 s
after	Passed: 22, Failed: 0 — 569 ms	Passed: 22, Failed: 0 — 332 ms

Both frameworks fail the identical fifteen. Nine of them are the hang and account for two of those two and
a quarter minutes — each burning its whole 15-second budget in an uninterruptible CLR loop, which is exactly
what an embedder's thread was doing:

Failed …NonIsoCalendarRangeTests.TheReportedMonthDifferencePastTheChineseRangeRaisesRangeError [15 s]
  Error Message:
   did not finish within 00:00:15: Temporal.PlainDate.from('1910-01-01').withCalendar('chinese')
     .until(Temporal.PlainDate.from('1900-01-03').withCalendar('chinese'), { largestUnit: 'year' })

The other six are the boundary date answered as if it were the result, in a millisecond:

Failed …ArithmeticPastACalendarRangeRaisesRangeErrorInsteadOfAnsweringWithTheBoundary(
    calendar: "chinese", from: "1950-01-01", call: "subtract({ years: 100 })") [1 ms]
  Expected string to be the same string, but they differ at index 0:
  "2101-01-28[u-ca=chinese]"   (actual)
  "RangeError"                 (expected)

Test suites

One dotnet test -c Release run on 1cfe8c34a:

suite	net472	net10.0
Jint.Tests	6857 passed, 0 failed, 4 skipped	6942 passed, 0 failed, 4 skipped
Jint.Tests.PublicInterface	1495 passed, 0 failed, 9 skipped	1502 passed, 0 failed, 9 skipped
Jint.Tests.CommonScripts	28 passed, 0 failed	28 passed, 0 failed
Jint.Tests.SourceGenerators	—	52 passed, 0 failed

Jint.Tests.Test262: 102,499 passed, 0 failed, 185 skipped (102,684 total) — the branch control,
unchanged. The full run reported two failures, both variants of
intl402/supportedLocalesOf-unicode-extensions-ignored.js timing out at 34 s against the engine's own
30-second default while three other test assemblies and a sibling suite shared the box. Re-run alone on the
same tree it passes in 2 s, and nothing in this change reaches Intl.supportedLocalesOf.

dotnet build -c Release: 0 errors, no new warnings.

🤖 Generated with Claude Code

https://claude.ai/code/session_014W5mbjGhyvgAS4pivXoc4S