These fields are modified by an invocation to CalendarResolveFields. All
callers currently don't care about these modifications, so they move the
CalendarFields struct into the AO. But it turns out that at least one AO
will care (InterpretTemporalDateTimeFields), thus we will need to take
by reference here.
Currently, AbstractOperations.h needs to include Time.h for the Time
structure. Soon, Time.h will need to include AbstractOperations.h for
structures defined there. To avoid a circular include, let's put the
ISO types into their own file, so that AO.h does not need to include
any JS type header.
Our BigInt implementation can store the negativity of the division
result in either the quotient or the remainder. This is exposed by an
upcoming prototype, which will reach this division with:
-432000000000000 / 86400000000000000000000
Which has the BigInt division result:
quotient = 0
remainder = -432000000000000
(Our old Temporal implementation also had this bug).
For example, consider the following operation:
const instance = new Temporal.PlainDate(2000, 5, 2);
instance.until("-271821-04-19");
The spec would have us enter a loop to compute the difference between
these dates by incrementing an intermediate date one day at a time.
Instead, we can do some math to skip ahead much closer to the desired
date.
We now have the Temporal facilities to implement the Date AOs which
parse UTC offset strings using the ISO8601 parser. This patch updates
those AOs and their callers in accordance with the Temporal spec.
This started with implementing TemporalMonthDayString. It turns out that
the facilities needed to parse that production includes nearly all the
helpers to parse each of:
TemporalDateTimeString
TemporalInstantString
TemporalMonthDayString
TemporalTimeString
TemporalYearMonthString
TemporalZonedDateTimeString
As most of these invoke the same helpers with different options. So,
all 6 of those productions are implemented here.
This also includes a stubbed Temporal.Duration.prototype.
Until we have re-implemented Temporal.PlainDate/ZonedDateTime, some of
Temporal.Duration.compare (and its invoked AOs) are left unimplemented.
Our Temporal implementation is woefully out of date. The spec has been
so vastly rewritten that it is unfortunately not practical to update our
implementation in-place. Even just removing Temporal objects that were
removed from the spec, or updating any of the simpler remaining objects,
has proven to be a mess in previous attempts.
So, this removes our Temporal implementation. AOs used by other specs
are left intact.
The Duration record no longer exists in Temporal. Implement it according
to the DurationFormat spec to prepare for its removal from our Temporal
implementation.
We also implement the DurationSign AO here as well, as the Temporal
implementation will now require a Temporal.Duration JS object.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
Instead, smuggle it in as a `void*` private data and let Javascript
aware code cast out that pointer to a VM&.
In order to make this split, rename JS::Cell to JS::CellImpl. Once we
have a LibGC, this will become GC::Cell. CellImpl then has no specific
knowledge of the VM& and Realm&. That knowledge is instead put into
JS::Cell, which inherits from CellImpl. JS::Cell is responsible for
JavaScript's realm initialization, as well as converting of the void*
private data to what it knows should be the VM&.
NanBoxedValue is intended to be a GC-allocatable type which is not
specific to javascript, towards the effort of factoring out the GC
implementation from LibJS.
Now that the heap has no knowledge about a JavaScript realm and is
purely for managing the memory of the heap, it does not make sense
to name this function to say that it is a non-realm variant.
The main motivation behind this is to remove JS specifics of the Realm
from the implementation of the Heap.
As a side effect of this change, this is a bit nicer to read than the
previous approach, and in my opinion, also makes it a little more clear
that this method is specific to a JavaScript Realm.
