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 helps make the overall codebase consistent. `class_name()` in
`Kernel` is always `StringView`, but not elsewhere.
Additionally, this results in the `strlen` (which needs to be done
when printing or other operations) always being computed at
compile-time.
Day and month name constants are defined in numerous places. This
pulls them together into a single place and eliminates the
duplication. It also ensures they are `constexpr`.
`static const` variables can be computed and initialized at run-time
during initialization or the first time a function is called. Change
them to `static constexpr` to ensure they are computed at
compile-time.
This allows some removal of `strlen` because the length of the
`StringView` can be used which is pre-computed at compile-time.
It makes no sense to require passing a global object and doing a stack
space check in some cases where running out of stack is highly unlikely,
we can't recover from errors, and currently ignore the result anyway.
This is most commonly in constructors and when setting things up, rather
than regular function calls.
This is taken from the abandoned error stacks proposal, which
already serves as the source of truth for the setter. It only requires
the this value to be an object - if it's not an Error object, the getter
returns undefined.
I have not compared this behavior to the non-standard implementations of
the stack property in other engines, but presumably the spec authors
already did that work.
This change gets the Sentry browser SDK working to a point where it can
actually send uncaught exceptions via the API :^)
By using the same NativeFunction constructor as plain ErrorConstructor
and passing the name, TypeError & co. will now include their name in
backtraces and such.
Eventually we should probably rely on [[InitialName]] for this, but for
now that's how it works.
The steps for creating a DeclarativeEnvironment for each iteration of a
for-loop can be done equivalently to the spec without following the spec
directly. For each binding creating in the loop's init expression, we:
1. Create a new binding in the new environment.
2. Grab the current value of the binding in the old environment.
3. Set the value in the new environment to the old value.
This can be replaced by initializing the bindings vector in the new
environment directly with the bindings in the old environment (but only
copying the bindings of the init statement).
On the code path where we are setting a TypedArray from another
TypedArray of the same type, we forgo the spec text and simply do a
memmove between the two ArrayBuffers. However, we forgot to apply
source's byte offset on this code path.
This meant if we tried setting a TypedArray from a TypedArray we got
from .subarray(), we would still copy from the start of the subarray's
ArrayBuffer.
This is because .subarray() returns a new TypedArray with the same
ArrayBuffer but the new TypedArray has a smaller length and a byte
offset that the rest of the codebase is responsible for applying.
This affected pako when it was decompressing a zlib stream that has
multiple zlib chunks in it. To read from the second chunk, it would
set the zlib window TypedArray from the .subarray() of the chunk offset
in the stream's TypedArray. This effectively made the decompressed data
from the second chunk a mis-mash of old data that looked completely
scrambled. It would also cause all future decompression using the same
pako Inflate instance to also appear scrambled.
As a pako comment aptly puts it:
> Call updatewindow() to create and/or update the window state.
> Note: a memory error from inflate() is non-recoverable.
This allows us to properly decompress the large compressed payloads
that Discord Gateway sends down to the Discord client. For example,
for an account that's only in the Serenity Discord, one of the payloads
is a 20 KB zlib compressed blob that has two chunks in it.
Surprisingly, this is not covered by test262! I imagine this would have
been caught earlier if there was such a test :^)
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/26a4c4f
No behavioral change as we already did this correctly, but I changed
some implicit JS::Value creations to explicit ones.
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/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.
