Before, If the cache was empty we would try and evict non-existant
entries and crash. So the fix is to make sure that we don't saturate
the cache with a single parse result.
Before this change, we would enumerate all the keys with
[[OwnPropertyKeys]], and then do [[GetOwnPropertyDescriptor]] twice for
each key as we went through them.
We now only do one [[GetOwnPropertyDescriptor]] per key, which
drastically reduces the number of proxy traps when those are involved.
The new trap sequence matches what you get with V8, so I don't think
anyone will be unpleasantly surprised here.
This is a normative change in the ECMA-402 spec. See:
7508197
In our implementation, we don't have the affected AOs directly, as we
delegate to ICU. So instead, we must ensure we provide ICU a locale with
the relevant extension keys present.
If the regex always matches the input, even if it's past the end, then
we need to stop execution of the regex when it's past the end. This
corresponds to step 13.a and prevents it from infinitely looping.
Reduced from: d98672060f/packages/react-i18n/src/utilities/money.ts (L10-L14)
This updates our local ICU overlay port to use ICU 76.1. This includes
Unicode 16 and CLDR 46.
Upstream vcpkg is not able to supply versions past 74 yet due to various
dependency issues, but we are able to use this version ourselves. The
overlay port now includes a patch to revert ICU's dependence on autoconf
2.72 for now, as this version is not yet available on all systems.
All of the test changes were cross-referenced with Firefox to ensure
correctness.
In ICU 76, the default was changed from "arab" to "latn". See:
c149724509
The whole point of these tests was to use a non-Latin numbering system.
This patch ensures that is the case to make following patches easier to
grok.
Instead of clamping to the limits allowed by ISOYearMonthWithinLimits,
clamp to the limits allowed by the type we are converting to (i32). This
allows some callers to then reject years outside that range.
The assertions can be hit when Temporal.Duration.prototype.round / total
are provided a PlainDate at the very limits of valid date-times. Tests
were recently added to test262 which trip these assertions, thus we are
now crashing in those tests. Let's throw a RangeError instead, as this
is the behavior expected by the tests.
The gist is that we need to construct an ICU date-time formatter for
each possible Temporal type. This is of course going to be expensive.
So instead, we construct the configurations needed for the ICU objects
in the Intl.DateTimeFormat constructor, and defer creating the actual
ICU objects until they are needed.
Each formatting prototype can also now accept either a number (as they
already did), or any of the supported Temporal objects. These types may
not be mixed, and their properties (namely, their calendar) must align
with the Intl.DateTimeFormat object.
If we were able to parse an ISO8601 Date string, but the parse results
in an invalid date (e.g. out of the min/max range), we should abort
parsing immediately.