...for the non-success state. This fixes a crash when parsing dates with
the year -1, as we would assert successful parsing ("year != -1").
Mixing Optional and -1 seems worse and more complicated than just using
Optional for all the values, so I did that instead.
It is defined as follows:
21.4.3.1 Date.now ( )
https://tc39.es/ecma262/#sec-date.now
The now function returns the time value designating the UTC date and
time of the occurrence of the call to now.
"Time value" is defined as:
21.4.1.1 Time Values and Time Range
https://tc39.es/ecma262/#sec-time-values-and-time-range
An ECMAScript time value is a Number, either a finite integral
Number representing an instant in time to millisecond precision or
NaN representing no specific instant.
By flooring the value we match the behavior in the Temporal proposal's
Temporal.ZonedDateTime.prototype.epochMilliseconds getter:
4. Let ms be RoundTowardsZero(ℝ(ns) / 10^6).
With that being defined as:
13.30 RoundTowardsZero ( x )
https://tc39.es/proposal-temporal/#sec-temporal-roundtowardszero
1. Return the mathematical value that is the same sign as x and
whose magnitude is floor(abs(x)).
This is makes the last of the currently 15 Temporal tests in test262
work, which compares Temporal.now.instant() with Date.now() :^)
All regex flags supported by LibJS currently correspond to a LibRegex
option, but this is not the case for the RegExp.prototype.hasIndices
proposal, which is handled entirely in RegExpBuiltinExec. Remove the
flag mapping to prepare for this. This incurs a bit of an optimization
loss in the flag getters, as we now do a substring search, but we can
revisit the getter implementation if it becomes an issue.
Our RegExpBuiltinExec implementation differed from the spec in some
areas such as handling of the sticky/global flags and updating the
lastIndex property.
This allows passing an existing RegExp object (or an object that is
sufficiently like a RegExp object) as the "pattern" argument of the
RegExp constructor.
As an abstraction, RegExpExec should not assume that the RegExp object
being used is "this" object. Instead, it should only interact with the
provided object.
This prepares for some methods, such as @@split, which invoke RegExpExec
with a secondary RegExp object.
Not all of the TypedArray prototype methods and accessors require
detached buffer validation (only the ones who call ValidateTypedArray)
so this behaviour was split from typed_array_from and the usage was
updated per the spec in each location.
create_from() casts the value to a 64 bit integer and then creates two
words from it, which is not necessary if we only pass values to it that
fit into a single word (32 bit integer).
Also make them use UnsignedBigInteger as the previously missing SBI
divided_by() overload is now implemented.
