From what I understand, the suspension steps are not required now,
or in the future for our implementation, or any other. The intent
is already implemented in the spec pushing on another execution
context to the stack and leaving the running execution context as-is.
The resume steps are a slightly different story as there is some subtle
behavior which the spec is trying to convey where some custom logic may
need to be done when one execution context changes from one to another.
It may be worth implementing those steps at a later point in time so
that this behavior is a bit easier to follow in those cases.
To make the situation more confusing - from what I can gather from the
spec, not all cases that the spec mentions resume actually means
anything normative. Resume is only _actually_ needed in a limited set
of locations.
For now, let's just remove the unneeded FIXMEs that indicate that there
is something to be done for the suspension steps, as there is not, and
leave the resume steps as is.
The assertions can be hit when Temporal.Duration.prototype.round / total
are provided a PlainDate at the very limits of valid date-times. Tests
were recently added to test262 which trip these assertions, thus we are
now crashing in those tests. Let's throw a RangeError instead, as this
is the behavior expected by the tests.
This is an editorial change in the Temporal proposal. See:
630b043
This also changes the second argument of this AO to not use the alias of
TimeDuration, as that should not be used to refer to epoch nanoseconds.
This was missed in commit 2d9405e5d7.
C++ will jovially select the implicit conversion operator, even if it's
complete bogus, such as for unknown-size types or non-destructible
types. Therefore, all such conversions (which incur a copy) must
(unfortunately) be explicit so that non-copyable types continue to work.
NOTE: We make an exception for trivially copyable types, since they
are, well, trivially copyable.
Co-authored-by: kleines Filmröllchen <filmroellchen@serenityos.org>
`AsyncBlockStart` was still doing a `DisposeResources` call as
specified in older drafts of the `explicit-resource-management`
proposal, but the latest draft no longer does this, and it is
causing crashes when combined with the `array-from-async` proposal.
Lazily coercing might have made sense in the past, but since hashing
and comparing requires the `PropertyKey` to be coerced, and since a
`PropertyKey` will be used to index into a hashmap 99% of the time,
which will hash the `PropertyKey` and use it in comparisons, the
extra complexity and branching produced by lazily coercing has
become more trouble than it is worth.
Remove the lazy coercions, which then also neatly allows us to
switch to a `Variant`-based implementation.
The gist is that we need to construct an ICU date-time formatter for
each possible Temporal type. This is of course going to be expensive.
So instead, we construct the configurations needed for the ICU objects
in the Intl.DateTimeFormat constructor, and defer creating the actual
ICU objects until they are needed.
Each formatting prototype can also now accept either a number (as they
already did), or any of the supported Temporal objects. These types may
not be mixed, and their properties (namely, their calendar) must align
with the Intl.DateTimeFormat object.
If we were able to parse an ISO8601 Date string, but the parse results
in an invalid date (e.g. out of the min/max range), we should abort
parsing immediately.
