The three major changes are:
- Parsing parameters, the function body, and then the full assembled
function source all separately. This is required by the spec, as
function parameters and body must be valid each on their own, which
cannot be guaranteed if we only ever parse the full function.
- Returning an ECMAScriptFunctionObject instead of a FunctionExpression
that needs to be evaluated separately. This vastly simplifies the
{Async,AsyncGenerator,Generator,}Function constructor implementations.
Drop '_node' from the function name accordingly.
- The prototype is now determined via GetPrototypeFromConstructor and
passed to OrdinaryFunctionCreate.
First, this adds a constructor to the Date object to be created from a
plain double. This is a first step to removing Core::DateTime as the
basis for the Date object. A subsequent commit will remove the now-
unused data from the object.
Next, this implements the constructor in accordance to the spec. The
constructor when NewTarget is undefined no longer allocates a Date on
the heap. The other constructor properly uses recently created AOs to
handle time zone and ensure the created [[DateValue]] is valid. Other
methods on the constructor (Date.now) have not been touched yet.
Last, the prototype is reimplemented. Again, we use other AOs to handle
time zones and time clipping. Not all prototypes are fixed; most of them
are, but a few (e.g. Date.prototype.getTimezoneOffset) were not fixed,
but left in a mostly unimplemented state for another commit.
In all of the above, spec comments are added. This is a rather large
change; but it's tough to do any of these parts individually without
breaking everything else.
length_in_code_units() returns a size_t, which is 64-bit unsigned
in i686 builds. `size + (i32)int_length` hence produced a 64-bit
unsigned result, so a negative value would wrap around and become
a very large number.
As fix, just omit the cast -- we assign the result of max() to
a double anyways.
With this, all test262 tests in annexB/built-ins/String/prototype pass.
Intl.DisplayNames v2 adds "calendar" and "dateTimeField" types, as well
as a "languageDisplay" option for the "language" type. This just adds
these options to the constructor.
Two issues:
- The intended range was 9 characters starting from index 1. Since the
second argument to String::substring() is the length, 10 is
potentially reading further than the string's length (when only
providing one fraction digit), causing an assertion failure crash.
- The spec's intention to skip the decimal separator by starting at
index 1 is incorrect, no decimal separator is present in the result of
parsing TimeZoneUTCOffsetFractionalPart. I filed a spec fix for this,
see: https://github.com/tc39/proposal-temporal/pull/1999
As all variables and numeric literals in the expression have an integral
data type, it would evaluate to an int and could easily overflow as
we're multiplying seconds with 10^9.
Introduce a floating point literal into the expression to make it result
in a double.
We can now recognize & normalize all time zones from the IANA time zone
database and not just 'UTC', which makes the LibJS Temporal
implementation a lot more useful! Thanks to the newly added LibTimeZone,
this was incredibly easy to implement :^)
This already includes these recent editorial changes in the Temporal
spec: 27bffe1
Previously parse_time_zone_numeric_utc_offset_syntax() would return true
to indicate success when parsing a string with an invalid number of
digits in the fractional seconds part (e.g. 23:59:59.9999999999).
We need to check if the lexer has any characters remaining, and return
false if that's the case.
This fixes all failing Date.UTC test262 tests, which failed due to not
handling invalid input and evaluating inputs out of order. But this also
avoids using timegm(), which doesn't work on macOS for years before 1900
(they simply return -1 for those years).
Partially addresses #4651. Date.parse.js still fails.
When searching for the locale-specific flexible day period for a given
hour, we were neglecting to handle cases where the period crosses 00:00.
For example, the en locale defines a day period range of [21:00, 06:00).
When given the hour of 05:00, we were checking if (21 <= 5 && 5 < 6),
thus not recognizing that the hour falls in that period.
As noted in the prototype comments, this implementation becomes less
accurate as the precision approaches the limit of 100. For example:
(3).toPrecision(100)
Should result in "3." followed by 99 "0"s. However, due to the loss of
accuracy in the floating point computations, we currently result in
"2.9999999...".
Since years don't have a constant amount of seconds because they can be
leap years no constant will work in all cases. We now test a timezone in
both the positive and negative direction and check that at least one
worked. Assuming years are at least 2 days long this will always pass
at least one test.
Some locales do not define morning, night, etc. day period ranges.
TR-35 states they should fall back to the fixed day periods AM and PM.
Add a test case for the "as" locale, which is one such locale, to ensure
its AM/PM symbols are used.
For the test cases changed here, we now recognize "morning2" and
"afternoon2" from the CLDR, so the expected results now match the specs
and other engines.
