This allows `import "./foo"` to succeed, even if the file is actually
called `foo.js`. IDEs commonly exclude file extensions in auto-imports.
Closes#14364.
The existing code looks innocently correct, implementing the following
step:
3. If IsCallable(func) is false, set func to the intrinsic function
%Object.prototype.toString%.
as
return ObjectPrototype::to_string(vm, global_object);
However, this misses the fact that the next step calls the function with
the previously ToObject()'d this value (`array`):
4. Return ? Call(func, array).
This doesn't happen in the current implementation, which will use the
unaltered this value from the Array.prototype.toString() call, and make
another, unequal object in %Object.prototype.toString%. Since both that
and Array.prototype.toString() do a Get() call on said object, this
behavior is observable (see newly added test).
Fix this by actually doing what the spec says and calling the fallback
function the regular way.
This fixes 2 bugs in our current implementation:
* Properties deleted during iteration were still being iterated
* Properties with the same name in both the object and it's prototype
were iterated twice
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 :^)
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 :^)
Previously the variable and lexical environments were already kept in a
NativeFunction call. However when we (try to) call a private method from
within an async function we go through async_block_start which sets up
a NativeFunction to call.
This is technically not exactly as the spec describes it, as that
requires you to actually "continue" the context. Since we don't have
that concept (yet) we use this as an implementation detail to access the
private environment from within a native function.
Note that this not allow general private environment access since most
things get blocked by the parser already.
Other engines don't give NaN if there is at least one digit after the
dot for milliseconds. We were much stricter and required exactly three
digits.
But there is real world usage of different amounts of digits such as
discord having three extra trailing zeros.
