This reverts commit cdcbbcf48b.
It made MicroBench/call-*-args.js faster, but some of the macro
benchmarks got significantly slower on macOS, so let's revert until we
understand it better.
Instead of always checking if we're about to return an empty completion
value in Interpreter::run_executable(), we now coerce empty completions
to the undefined value earlier instead.
This simplifies the most common path through run_executable(), giving us
a small speedup.
Instead of using this span, we can just use the getter that calculates
the base of the register/constant/local/argument array based on the
ExecutionContext's own address.
Asserting that a sample is not provided if the resource is not Inline
is not quite valid, since Eval, TrustedTypesSink and TrustedTypesPolicy
also provide a sample.
Spec issue: https://github.com/w3c/webappsec-csp/issues/788
We don't need to return two values; running an executable only ever
produces a throw completion, or a normal completion, i.e a Value.
This necessitated a few minor changes, such as adding a way to check
if a JS::Cell is a GeneratorResult.
In several content calculation methods in FormattingContext, we assumed
that if create_independent_formatting_context_if_needed() fails the
input Layout::Box is a BlockContainer; however, the web platform test
css/css-pseudo/parsing/marker-supported-properties-in-animation.html is
one scenario where the input is a Layout::ListItemMarkerBox instead and
there is no FormattingContext supported for it yet.
By handling call instructions in an inline (C++) function, we were
breaking the alloca() optimization and adding stack overhead. We fix
this by using a macro instead. It looks awful but it works.
1.07x speedup on MicroBench/call-00-args.js
Our Core::System::is_socket() helper is not very robust, as it was
incorrectly marking m_fd as a non-socket fd. This meant we were trying
to call CLoseHandle() on a socket which fails. We can just call
closesocket() directly given we are in an explicit socket-only context.
When shutting down helper processes, PosixSocketHelper::close() in
SocketWindows when trying to close the socket fd with
WSANOTINITIALISED. This was due to us initiating WinSock2 during static
initialization and presumably also not terminating WinSock2 properly.
Similar to WinSock2 initiation, calling CRT during static
initialization is considered dangerous given the CRT DLL itself may not
yet be initialized.
Because of the above, we move to perform this Windows-specific
runtime setup/teardown calls into the main() functions.
Given the RequestServer created the request fd with socketpair() on
Windows and pipe2() on Unix, this abstraction avoids inlined ifdef soup
by hiding the details of how the AK::Stream and Core::Notifier are
created.
This simplifies function entry/exit and lets us just walk away from the
used ExecutionContext instead of resetting a bunch of its state when
returning control to the caller.
Instead of having ExecutionContext track function names separately,
we give FunctionObject a virtual function that returns an appropriate
name string for use in call stacks.
This commits puts the strict mode flag in the header of every bytecode
instruction. This allows us to check for strict mode without looking at
the currently running execution context.
The GC::Ref smart pointer is always non-null, so there's no need for it
to be convertible to bool.
This exposed a small number of unnecessary null checks which we remove.
This fixes a silly bug where we would crash when parsing a multi-layer
mask shorthand property that contained the no-clip keyword but no value
for mask-origin.
Fixes a crash when parsing the CSS of https://www.browserbase.com/. The
site still has other, unrelated problems though.
On 64-bit Windows, long's are only 4 bytes. This meant that when the
client is deocding the IPC message from a async_request_finished call,
we were corrupting the RequestTimingInfo field and all the fields after
it as we were 4 bytes off.
