When we create a Date object from a timestamp, or set its value by way
of Date.prototype.setTime, the timestamp is interpreted as UTC. Change
test expecatations against such instances to use UTC as well.
u64 is not big enough to hold extremely large numbers, such as
4.192938423e+54. This would cause an integer underflow on the radix
index when performing something like `toString(36)` and thus cause an
OOB Array read.
This makes it ever-so-slightly faster, but more importantly, it fixes
the bug where a `/\//` regex's `source` property would return `\\/`
("\\\\/") instead of `\/` due to the existing '/' -> '\/' replace()
call.
For example the words "can't" and "32.3" should not have boundaries
detected on the "'" and "." code points, respectively.
The String test cases fixed here are because "b'ar" is now considered
one word.
This is a normative change in the Intl.NumberFormat V3 spec. See:
08f599b
Note that this didn't seem to actually affect our implementation. The
Unicode spec states:
https://www.unicode.org/reports/tr35/tr35-53/tr35-numbers.html#Plural_Ranges
"If there is no value for a <start,end> pair, the default result is end"
Therefore, our implementation did not have the behavior noted by the
issue this normative change addressed:
const pr = new Intl.PluralRules("en-US");
pr.selectRange(1, 1); // Is "other", should be "one"
Our implementation already returned "one" here because there is no such
<start=one, end=one> value in the CLDR for en-US. Thus, we already
returned the end value of "one".
This is a normative change in the Intl.NumberFormat V3 spec. See:
29acfc6
This is to allow Intl.PluralRules to use these options, as they were in-
effect required by later AOs anyways.
Explicitly disallow constructing a CanonicalIndex from a floating point
type without going through a factory method that will throw when the
provided index cannot fit in a u32.
Before these tests could be flaky if they happened to be called around
the edge of a second. Now we try up to 5 times to execute the tests
while staying within the same second.
We were mistakenly trying to append UTF-16 code units to a StringBuilder
via the append(char) API. This patch fixes that by accumulating the
result in a Vector<u16> instead.
This'll be a bit worse for performance, since we're now doing additional
UTF-16 string conversions, but we're going for correctness at this stage
and can worry about performance later.
