This is an editorial change in the Temporal spec.
See: 26a4c4f
No behavioral change as we already did this correctly, but I changed
some implicit JS::Value creations to explicit ones.
This is an editorial change in the Temporal spec.
See:
- 7fbdd28
- f666243
- 8c7d066
- 307d108
- d9ca402
In practical terms this means we can now get rid of a couple of awkward
assertion steps that were no-ops anyway, since the types are enforced
by the compiler.
This is an editorial change in the Temporal spec.
See: 983902e
We already had these defined as structs, but now they're properly
defined in the spec (opposed to the previous anonymous records), and we
don't have to make up our own names anymore :^)
Note that while we're usually not including 'record' in the name, in
this case the 'Duration Record' has a name clash with the Duration
object. Additionally, later editorial changes introduce CreateFooRecord
AOs, so let's just go with FooRecord structs here.
Resolve TODOs suggesting the use of a strongly typed MarkedValueList
(a.k.a. MarkedVector<T>) in the following AOs:
- get_possible_instants_for()
- disambiguate_possible_instants()
Since VM::exception() no longer exists this is now useless. All of these
calls to clear_exception were just to clear the VM state after some
(potentially) failed evaluation and did not use the exception itself.
No need to take the spec literally here since we know the input values
are guaranteed to be integral numbers. Use AK string to number parsing
functionality instead and save a couple of PrimitiveString allocations.
This matches what we already do in parse_temporal_time_zone_string().
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.
A sign that's either the value 1 or -1 should obviously not have an
unsigned data type :^)
This would cause it to become 255 for the negative offset case, which
would then completely screw up the offset_nanoseconds calculation as it
serves as a multiplier.
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.
Instead of using plain objects as Iterator records, causes confusion
about the object itself actually being its [[Iterator]] slot, and
requires non-standard type conversion shenanigans fpr the [[NextValue]]
and [[Done]] internal slots, implement a proper Iterator record struct
and use it throughout.
Also annotate the remaining Iterator AOs with spec comments while we're
here.
This matches the text of the spec, and is more correct since the
variable is being updated, not defined it.
See: 5ab1822
---
I also changed `test_year += 1` to `test_year++` for consistency with
step 11.c that has the same description.
