This is no longer done. One of the comments is also innacurate for a
second reason - the call stack is never empty in that case, and is
verified as such only a few lines above.
From what I understand, the suspension steps are not required now,
or in the future for our implementation, or any other. The intent
is already implemented in the spec pushing on another execution
context to the stack and leaving the running execution context as-is.
The resume steps are a slightly different story as there is some subtle
behavior which the spec is trying to convey where some custom logic may
need to be done when one execution context changes from one to another.
It may be worth implementing those steps at a later point in time so
that this behavior is a bit easier to follow in those cases.
To make the situation more confusing - from what I can gather from the
spec, not all cases that the spec mentions resume actually means
anything normative. Resume is only _actually_ needed in a limited set
of locations.
For now, let's just remove the unneeded FIXMEs that indicate that there
is something to be done for the suspension steps, as there is not, and
leave the resume steps as is.
For example, https://locals.com/site/discover has a script with an
object of the form:
var f = {
parser: {
sync() {},
async async() {},
}
};
We were previously throwing a syntax error on the async function, as we
specifically did not allow using "async" as a function name here.
Even though calling delete on a super property will ultimately throw a
ReferenceError, we must return the allocated register for the result of
the delete operation (which would normally be a boolean). If the delete
operation is used in a return statement, the bytecode generator for the
return statement must be able to assume the statement had some output.
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:
https://github.com/tc39/proposal-temporal/commit/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.
The source code position cache was moved from a line based approach
to a "chunk"-based approach to improve performance on large, minified
JavaScript files with few lines, but this has had an adverse effect
on _multi-line_ source files.
Reintroduce some of the old behaviour by caching lines again, with
some added sanity limits to avoid caching empty/overly small lines.
Source code positions in files with few lines will still be cached
less often, since minified JavaScript files can be assumed to be
unusually large, and since stack traces for minified JavaScript
are less useful as well.
On WPT tests with large JavaScript dependencies like
`css/css-masking/animations/clip-interpolation.html` this reduces the
amount of time spent in `SourceCode::range_from_offsets` by as much as
99.98%, for the small small price of 80KB extra memory usage.
