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.
We don't need nanosecond precision here anyways, as we only display
millisecond resolution.
This uses our simple duration formatter from AK, which is updated to
accept a Duration here. This method did not have any users after the
move from Serenity.
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.
Previously it was only pushing the module context for the call to
capture the module execution context. This is incorrect, as the capture
occurs upon function construction. This resulted in it capturing the
execution context that execute_module was called from, instead of the
newly created module_context.
f87041bf3a/Libraries/LibJS/Runtime/ECMAScriptFunctionObject.cpp (L92)
This can be demonstrated with the following setup:
index.html:
```html
<script>
var foo = 1;
</script>
<script type="module">
import {test} from "./scriptA.mjs";
</script>
```
scriptA.mjs:
```js
function foo() {
return {a: "b"};
}
export let test = await foo();
```
Before this fix, this would throw:
```
[TypeError] 1 is not a function (evaluated from 'foo')
at module code with top-level await
at module code with top-level await
at <unknown>
at <unknown>
```
Fixes#2245.
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
