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.
And make ErrorType definitions use a better hanging-indent style, to
make it easier to maintain going forward.
i.e. instead of:
M(VeryLongErrorNameHere, "very long error "
"message across multiple "
"lines"
We now have:
M(VeryLongErrorNameHere,
"very long error message across multiple "
"lines")
We were passing types like ISODate by reference so that they could be
used as forward-declarations. But after commit 021a5f4ded, we now have
their full definitions anywhere they're needed. So let's pass ISODate by
value everywhere consistently - it is only 8 bytes.
It was a bit of a semantic mistake too use this alias too eagerly.
Namely, it should not be used to refer to epoch nanoseconds. We now only
use the TimeDuration alias where the spec refers to a value as a time
duration.
