Bump Jint from 4.16.2 to 4.16.4

[dependabot]

Updated Jint from 4.16.2 to 4.16.4.

Release notes

Sourced from Jint's releases.

4.16.4

Jint 4.16.4 is a maintenance release from the 4.x branch. It backports correctness and conformance fixes from main — three of them for scripts that could end the host process — together with a few measured performance improvements, and nothing in it changes an existing API or an existing default. If you are on 4.16.3 it is a drop-in update — every public signature is the one 4.16.0 shipped, on all five target frameworks, and the per-framework snapshots in Jint.Tests.PublicInterface/Verify/ are unchanged. main remains 5.0.0 development; what is coming there is recorded as it lands in docs/v5-migration.md.

Highlights

A number reads as the same double on every target framework. Before .NET 9, the runtime's ulong-to-double and string-to-double conversions double-round, and Jint inherited that: a whole-number literal in [2⁶³, 2⁶⁴) held a different double on .NET Framework and .NET 8 than on .NET 10 (#​3531); parseFloat, Number and JSON.parse mis-rounded past their integer window on .NET Framework, and JSON.parse('1e999') threw a CLR OverflowException out of the engine instead of answering Infinity (#​3535); a fraction or exponent literal could land one ULP away on .NET Framework (#​3538); and parseInt and wide radix literals now hold the Number nearest the integer they denote on every framework, with a legacy octal no longer re-read as decimal (#​3537). The string-to-number lanes and trim now accept exactly the white space the parser does — U+0085 NEL no longer counts, and a byte-order mark no longer breaks Number or BigInt (#​3542) — and an exponent scan no longer clamps at 10⁶ (#​3593). All six arrive together as #​4120, because they share one parser. This changes numeric results — to the correct ones. The literal and string-to-number fixes change answers on .NET Framework only; parseInt, radix literals, the white-space set and the exponent clamp change them on every framework.

BigInt('+12') is 12n. The decimal spelling of a StringIntegerLiteral may carry a sign, so a leading + is accepted there and only there; BigInt('+0x10') stays a SyntaxError (#​4121).

A split keeps its segments when a constraint runs script. String.prototype.split filled a thread-shared scratch list and checks constraints every 10,000 segments; a host Constraint that ran script on the same thread could clear the list an outer split was still filling, which then returned only the segments added afterwards (#​4122).

An overload is not a fit for a number it cannot hold. Overload scoring gated float, short, byte and their kin on the value fitting, but not int and long — so 3000000000 was a perfect match for an int parameter, the wider overload beside it was never tried, and the host saw a CLR OverflowException rather than a catchable JavaScript error (#​4123).

Intl's locale lookup stops paying for a culture it does not need. BestAvailableLocale resolved a CultureInfo on every truncation step even though the available-locale set answers almost every lookup by itself; it now resolves one only when the set cannot answer (#​4124).

Intl.Locale canonicalizes every Unicode extension keyword value. UTS #​35 canonicalizes a keyword's value in two halves — the CLDR bcp47 aliases, and the removal of a value of "true" — and Jint did only the first, while Intl.Locale's own tag scanner did neither. So en-u-ca-true kept its true, en-u-kb-yes kept its yes although the data aliases it to true, and en-u-ks-primary was never aliased to level1 on the tag path. The firstDayOfWeek option was read as a Number before a String and cast to int, so 0.5 resolved to "sun" where the spec rejects it, and NaN and Infinity became whatever the framework's cast made of them — which differed between .NET and .NET Framework (#​4156).

An object used as a rotating cache stops compacting forever. A property removed from an object's store leaves a tombstone, so that a re-added key keeps its creation order. Removing the newest entry already reclaimed its slot; removing the oldest — the shape of a bounded cache, a fresh name in and the oldest out — left a hole each time, and the table compacted every capacity − live additions although the live set never grew: a 16-key rotation settled on a capacity of 64 and compacted 209 times per 10,000 steps. The entries are now a window that may wrap around the array, so a removal at either end retires its slot; the same rotation never resizes and settles on 32 (#​4155).

Chains that script can make as long as it likes no longer end the process. Resolving a property through a prototype chain recursed one native frame per link, so a 20,000-deep { __proto__: x } chain overflowed the native stack on a read, a write, an in or a with lookup and ended the process — nothing thrown, nothing for a catch to see (#​4170, from #​4078; issue #​4076, reported by @​Tielem). [[Get]], [[Set]] and [[HasProperty]] now walk the chain in a loop, so an ordinary or shaped-host-prototype chain of any depth simply answers. Function.prototype.bind chains had the same shape in IsConstructor and in the realm lookup new and Reflect.construct perform, and those are loops now too (#​4169, from #​4165); on .NET Framework the JIT happened to turn both into tail calls, so the process death was a .NET 8 / .NET 10 one.

Two chains cannot be flattened, because each link has work of its own to do on the way back out: a proxy forwarding to a proxy, and host object wrappers stacked on each other (#​4170, from #​4125; issue #​4087). Those are probed instead, and raise a catchable RangeError — when Options.Constraints.StackOverflowGuard is on. On 4.x that guard remains opt-in (it becomes the default only in 5.0), so an engine left at its defaults still ends the process on a deep enough proxy chain. If you run script you do not control, turn the guard on; with it on, a 20,000-link proxy chain used as an array's constructor or as Reflect.construct's newTarget now raises RangeError where it used to end the process.

% stops allocating for numbers. The remainder operator now takes the unboxed numeric lane multiplication and division already used, so sum += i % 97 reads a numeric counter without materialising a JsNumber per step — on the benchmark's arithmetic loop, allocation per run drops from 2.87 MB to under 1 KB (#​4167, from #​4154).

Intl.Locale.prototype.getWeekInfo reads the region the specification picks. It read CLDR's week data for the tag's literal region subtag only, so a tag without one got the world's week and the -u-rg- and -u-sd- keywords were ignored. It now follows RegionPreference: a -u-rg- override, then the region subtag, then a -u-sd- subdivision's region, then the region Add Likely Subtags supplies, then 001. This changes answers — new Intl.Locale('en').getWeekInfo().firstDay is now 7 (en is likely en-US, where the week starts on Sunday) rather than 1, and en-US-u-rg-gbzzzz answers 1 rather than 7 — in each case to what the specification and every browser give (#​4168, from #​4163).

Verification

Every backport was verified failing-first: its tests were run against the unfixed 4.x tree on .NET 10 and .NET Framework 4.7.2, then with the change.

PR	tests	unfixed .NET Framework	unfixed .NET 10	after
#​4120 (#​3531)	whole-number literals, 22	15 fail	0 fail	all pass
#​4120 (#​3535)	string to number, 41; JsonTests, 170	22 + 8 fail	0 fail	all pass
#​4120 (#​3538)	fraction / exponent literals, 50	16 fail	0 fail	all pass
#​4120 (#​3537)	parseInt, 124; radix literals, 21	96 + 12 fail	96 + 12 fail	all pass
#​4120 (#​3542)	white space, 35	22 fail	22 fail	all pass
#​4120 (#​3593)	exponent clamp, 5	1 fail	1 fail	all pass
#​4121	StringToBigInt, 46	16 fail	16 fail	all pass
#​4122	constraint re-entrancy, 2	1 fail	1 fail	all pass
#​4123	numeric overload range, 20	10 fail	10 fail	all pass
#​4124	culture lookup count, 8	1 fail	1 fail	all pass
#​4155	creation order across rotation, 53	6 fail	6 fail	all pass
#​4156	Intl.Locale canonicalization, 81	30 fail	30 fail	all pass
#​4167	modulo lane, 8 (semantics only)	0 fail	0 fail	all pass — the lane is proven by allocation: 2,873,104 B → 784 B per run
#​4168	getWeekInfo region preference, 26; test262 getWeekInfo region files, 8	13 + 8 fail	13 + 8 fail	all pass
#​4169	bound and proxy chain walks, 3	pass (JIT tail-calls)	3 end the process	all pass
#​4170	deep prototype (9), shaped-prototype (8), trapless proxy (3) and wrapper (2) chain rows, plus the PlainObject census	12 end the process, 1 fails, census fails	19 end the process, census fails	all pass

Release diagnostics on the tagged commit's tree (a19802dda703), in Release: Jint.Tests 7,655 (net10.0) and 7,570 (net472); Jint.Tests.PublicInterface 1,903 and 1,895; Jint.Tests.CommonScripts 28 and 28; Jint.Tests.SourceGenerators 52; the host-contract verification leg (JINT_HOST_CONTRACT_VERIFICATION=1) 7,655 / 7,570 and 1,907 / 1,899 — zero failures anywhere, and the PublicInterface surface snapshots unchanged. test262: 102,509 passed, 0 failed, 175 skipped — the 4.x control plus the eight getWeekInfo cases #​4168 un-excluded. CI passed the same tree on Linux x64, Linux ARM64, Windows, macOS and the host-contract leg.
... (truncated)

4.16.3

Jint 4.16.3 is a maintenance release from the 4.x branch: correctness and conformance fixes backported from main, and nothing that changes an existing API or an existing default. If you are on 4.16.2 it is a drop-in update — every public signature is the one 4.16.0 shipped, on all five target frameworks, and the per-framework snapshots in Jint.Tests.PublicInterface/Verify/ are unchanged. main remains 5.0.0 development; what is coming there is recorded as it lands in docs/v5-migration.md.

Highlights

A long-lived engine stops accumulating what it has already run. Evaluate(string) and Execute(string) parse a fresh Script on every call, and the engine kept every one of them. Three of the four per-engine handler-tree caches already reset wholesale at 2048 entries so a host streaming endless distinct sources cannot grow them without bound; the fourth, _evaluatedScripts, never got that ceiling and held its keys strongly, retaining the AST of every distinct script the engine had ever evaluated — about 528 bytes per call, climbing forever and reclaimed by nothing short of dropping the engine (#​4116). The realm's tagged-template map had the same shape and a harder constraint: Realm._templateMap was a Dictionary<Node, JsArray>, strong on both ends and never cleared, costing roughly 1.35 KB per call for a frozen array and its raw array. A ceiling is no remedy there, because evicting a live template site is script-visible — f() === f() must hold for one site — so it becomes a ConditionalWeakTable<Node, WeakReference<JsArray>>, weak on both halves (#​4119). Both matter most to exactly the embedding that looks innocuous: one engine, kept for the lifetime of the process, handed ad-hoc source.

A suspended frame no longer dereferences what the suspension produced. await and yield suspend by returning a plain undefined, and the enclosing member link turns that into a sentinel reference that every consumer must recognise before reading. Nine did not, so they read undefined.undefined and raised a TypeError inside a frame that was already suspended. AsyncBlockStart swallowed that throw, but not before the statement-list resume position had been cleared on the way out — so the resume replayed the body from the first statement: one extra run of every un-awaited side effect per suspension point, and a re-entrancy guard silently truncating the rest. In a generator nothing swallows it and the TypeError comes straight out of next(). Two shapes were wrong answers rather than repeated ones — (await p).x = 1 rejected the promise, and o[await k] = 1 assigned to the literal key "undefined" instead of the real one — and for await ((await p).a of it) never terminated at all. Optional chaining was not the trigger despite where the report put it: the guarded fast lane needs a literal property name, so every computed member read of an awaited or yielded value fell through, (await p)[0] as much as (await p)[k] (#​4089, reported by @​salihvatanseverv in #​4086).

Verification

Every change was verified failing-first against the unfixed branch. The suspension fix is pinned by 35 new cases in Jint.Tests/Runtime/SuspendedOptionalChainTests.cs: against 4.16.2's code 28 fail and 6 pass on both .NET 10 and .NET Framework 4.7.2, with a 35th — the for await shape — hanging the test host outright rather than failing; after the fix all 35 pass on both. The retention fixes are pinned by Jint.Tests/Runtime/GarbageCollectionTests.cs and TaggedTemplateCacheTests.cs.

Release diagnostics on the tagged commit, in Release: Jint.Tests 7,170 (net10.0) and 7,085 (net472); Jint.Tests.PublicInterface 1,852 and 1,844; Jint.Tests.CommonScripts 28 and 28; Jint.Tests.SourceGenerators 52; the host-contract verification leg (JINT_HOST_CONTRACT_VERIFICATION=1) 7,170 / 7,085 and 1,856 / 1,848 — zero failures anywhere. test262: 102,498 passed, 183 skipped, with three files crossing the engine's default 30-second budget under whole-suite CPU contention and passing in three seconds when run alone.

The paired SunSpider and Dromaeo comparison against 4.16.2 was run after the tag rather than before it, which is a departure from how 4.16.2 was gated; it is recorded here because the result is what the release notes should carry, not the order it arrived in. No row regressed. Fifty-one rows, paired, alternating order, DefaultJob, on an idle machine: the three-round screen left two candidates clearing the sign-agreement and magnitude bar, both of them Dromaeo.StringBase64, and re-measuring those at eight rounds read −1.72% [−3.01, +1.98] and +0.30% [−3.10, +4.26] — no change, with a third parameter combination coming out faster. StringBase64 is the row Jint.Benchmark/AGENTS.md already documents as a three-round false positive, and it behaved as documented. The Cube control rows moved +0.6% to +0.8%, which is this machine's floor on rows the change cannot reach.

Nothing here is a performance change by intent. #​4119 does move a tagged-template lookup from a Dictionary to a ConditionalWeakTable and #​4089 adds suspension checks to several interpreter lanes, and neither is visible above the noise floor.

What's Changed

• Backport #​4115 to 4.x: bound the evaluated-script set by @​lahma in Backport #4115 to 4.x: bound the evaluated-script set sebastienros/jint#4116
• Backport #​4118 to 4.x: stop the realm's template map retaining every site it ran by @​lahma in Backport #4118 to 4.x: stop the realm's template map retaining every site it ran sebastienros/jint#4119
• Async and generators: a suspended frame dereferences nothing the suspension produced (backport of #​4088) by @​lahma in Async and generators: a suspended frame dereferences nothing the suspension produced (backport of #4088) sebastienros/jint#4089

Full Changelog: sebastienros/jint@v4.16.2...v4.16.3

Commits viewable in compare view.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)