This begins the process of aligning our implementation with the spec
with regard to using CalendarMethodsRecord. The main intent here is to
make it much easier to make normative changes to AOs which have been
updated to CalendarMethodsRecord.
While this does resolve various FIXMEs, many others above need to be
added in order to be able to pass through a CalendarMethodsRecord. The
use here aligns with what I can gather from the spec of what the
arguments to CreateCalendarMethodsRecord should be, but various AOs have
been updated so much with other changes it's not completely obvious.
Other AOs do not even exist in the latest version of the spec, but we
still rely on them.
As part of these updates, this commit coincidentally also fixes two
PlainDate roundingmode issues seen in test262 - a test of which is also
added in test-js. This issue boiled down to what appears to be an
observable optimization in the spec, where it can avoid calling
dateUntil in certain situations (roundingGranularityIsNoop).
However, the main goal here is to make it much easier to fix many more
issues in the future :^)
since/calendar-dateuntil-called-with-singular-largestunit.js ❌ -> ✅
until/calendar-dateuntil-called-with-singular-largestunit.js ❌ -> ✅
This has the guts of the old temporal AO BalanceDuration with some
differences such as an extra precision of one unit. This appears to be
important for different rounding modes to act as a tiebreaker.
It also does not have any logic regarding a zoned date time 'relative
to' - the spec seems to have this factored in a way where callers are
expected to perform this logic if neccessary.
This commit effectively just does a bulk update of this function to the
spec. Since there have been so many spec changes, no specific change was
made in mind, and many FIXMEs have been left for where we are still out
of date.
These changes also appear to include a normative change to the temporal
spec which was previously resulting in timeouts for some tests, and is
now resulting in a timeout.
Furthermore, this also resolves some crashes by protecting against
division by zero, instead throwing a RangeError. This can only happen
when a custom calender is provided which returns funky values. See:
https://github.com/tc39/proposal-temporal/commit/ed85e9
Diff Tests:
+8 ✅ -4 💀 -4 💥️
This patch adds two macros to declare per-type allocators:
- JS_DECLARE_ALLOCATOR(TypeName)
- JS_DEFINE_ALLOCATOR(TypeName)
When used, they add a type-specific CellAllocator that the Heap will
delegate allocation requests to.
The result of this is that GC objects of the same type always end up
within the same HeapBlock, drastically reducing the ability to perform
type confusion attacks.
It also improves HeapBlock utilization, since each block now has cells
sized exactly to the type used within that block. (Previously we only
had a handful of block sizes available, and most GC allocations ended
up with a large amount of slack in their tails.)
There is a small performance hit from this, but I'm sure we can make
up for it elsewhere.
Note that the old size-based allocators still exist, and we fall back
to them for any type that doesn't have its own CellAllocator.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
This removes a bunch of silly wrapping and unwrapping of Crypto
SignedBigInteger values in JS BigInt objects, which isn't even intended
by the spec - it just wants us to take an integer value, not a BigInt
specifically. Nice opportunity to remove a couple of allocations. :^)
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.
