Previously it was only pushing the module context for the call to
capture the module execution context. This is incorrect, as the capture
occurs upon function construction. This resulted in it capturing the
execution context that execute_module was called from, instead of the
newly created module_context.
f87041bf3a/Libraries/LibJS/Runtime/ECMAScriptFunctionObject.cpp (L92)
This can be demonstrated with the following setup:
index.html:
```html
<script>
var foo = 1;
</script>
<script type="module">
import {test} from "./scriptA.mjs";
</script>
```
scriptA.mjs:
```js
function foo() {
return {a: "b"};
}
export let test = await foo();
```
Before this fix, this would throw:
```
[TypeError] 1 is not a function (evaluated from 'foo')
at module code with top-level await
at module code with top-level await
at <unknown>
at <unknown>
```
Fixes#2245.
(cherry picked from commit 6319dedbcd4d6e448b4cc2615e62eba5ac576887)
The current shadow realm constructor implementation was based off a
merge request to the shadow realm proposal for integration into the
web platform. However, this merge request had a bug which we had
applied a workaround for by popping off the execution stack.
Since then, the spec has had an update of:
https://github.com/tc39/proposal-shadowrealm/commit/28b0cc
Which closer aligned the mainline spec to the proposed merge request.
Now, the original shadow realm proposal merge request has been closed
and a new one has been reopened with a much more minimal set of changes
that merely adds extra arguments to HostInitializeShadowRealm, which
this commit aligns with.
(cherry picked from commit 424a0cda936e018a9881f3e5898beb79d2212caa)
Noone needs to use this any more :^)
This is somewhat AD-HOC in the constructor as it is based on an open
shadow realm merge request, but applies the intent of the change without
any change in behaviour.
(cherry picked from commit b927d7f65870c94d0c7ead3f6bdd8e6f6f0ac887)
This is a new AO introduced in the spec which allows the
[[ExecutionContext]] slot of the ShadowRealm object to be removed.
(cherry picked from commit 3f24008b31d36c41c3bb841312914019073fac33)
The use of extract_parameter_arguments_and_body() here is to make things
a little less awkward. If we were to exactly follow spec there would be
an awkward handling of the case that no arguments were provided and we
needed to provide an empty string.
To do this, we would need to either:
- Provide an Optional<Value> for bodyString to CreateDynamicFunction
- Create a new empty PrimitiveString wrapped in a JS Value.
Either case is somewhat awkward. Instead, just refactor this logic
outside of CreateDynamicFunction and make the caller do it.
Otherwise, this commit prepares for the new definition of
HostEnsureCanCompileStrings.
(cherry picked from commit 6da0ac3aa71c991e18e96d721b1843c417cdab78)
When the cached value was not an accessor, it was simply ignored.
This is the value we really want, so we can just return it.
Shows up to 5x improvements on some benchmarks,
and 1.4x in general js-benchmarks.
(cherry picked from commit 77a46ab1b8d13f35b11a7bd08459752912dca1bf)
Async functions whose promise is never resolved were leaking, since they
had a strong root JS::Handle on themselves.
This doesn't appear to actually be necessary, since the wrapper will be
kept alive as long as it's reachable (and if it's not reachable, nobody
is going to resolve/reject the promise either).
This fixes the vast majority of leaks on Speedometer, bringing memory
usage at the end of a full run from ~12 GiB to ~3 GiB.
(cherry picked from commit b6a5b7e18626ce0dee11a25bb0d51d2e84d3c057)
This fixes an issue where a badly-timed garbage collection could swallow
a static field initializer.
Caught by running test262 in GC-on-every-allocation mode.
(cherry picked from commit 10724a7cb346e57b0b97e4bd54c13c5c604dbf9c)
We were miscalculating the length of the buffer in pointer-sized chunks,
which is what the conservative root scan cares about.
This could cause some values to be prematurely garbage-collected.
(cherry picked from commit 2fb3b6c542db3a86cbd1aa7e34d470e34c485372)
The `[[GetOwnProperty]]` internal method invocation in
`OrdinarySetWithOwnDescriptor` was being invocated again with the same
parameters in the `[[DefineOwnProperty]]` internal method that is also
later called in `OrdinarySetWithOwnDescriptor`.
The `PlatformObject.[[DefineOwnProperty]]` has similair logic.
This change adds an optional parameter to the `[[DefineOwnProperty]]`
internal method so the results of the previous `[[GetOwnProperty]]`
internal method invocation can be re-used.
(cherry picked from commit 69f96122b6150c22d1e8dc848c097cead2d2ae3f)
This is really just a type alias for NonnullGCPtr<T>, but it provides
a way to have non-owning non-visited NonnullGCPtr<T> without getting
yelled at by the Clang plugin for catching GC errors.
(cherry picked from commit 6a6618f5eab6e6a2c7c3fc03f8063cc6b497a0ec)
We were previously dumping the address of the cell pointer instead of
the address of the cell itself. This was causing mysterious orphans
in GC dumps, and it took me way too long to figure this out.
(cherry picked from commit e240084437ea0bfe03d83dc3533d4ee6214b7206)
The following syntax is valid:
```js
e?.example / 1.2
```
Previously, the `/` would be treated as a unterminated regex literal,
because it was calling the regular `consume` instead of
`consume_and_allow_division`.
This is what is done when parsing IdentifierNames in
parse_secondary_expression when a period is encountered.
Allows us to parse clients-main-[hash].js on https://ubereats.com/
(cherry picked from commit bd4c29322c945647c52ff4d8045c7529f8152b08)
There is no need to do a full linear search from start to end when
we can just remember the position and continue where we left off.
(cherry picked from commit f4e24762846cfb7a98054f700319d940173086bb)
If statements without an else clause generated jumps to the next
instruction, this commit fixes the if statement generation so that it
dosen't produce them anymore.
This is an example of JS code that generates the useless jumps
(a => if(a){}) ();
(cherry picked from commit 7865fbfe6d04a79a253a38eaec5c21c2bde110b5)
This avoids having to do O(n) contains() in the various flag accessors.
Yields a ~20% speed-up on the following microbenchmark:
const re = /foo/dgimsvy;
for (let i = 0; i < 1_000_000; ++i)
re.flags;
(cherry picked from commit 257ebea3645ab709be4a984100cc6478b289d0e6)
`find_binding_and_index` was doing a linear search, and while most
environments are small, websites using JavaScript bundlers can have
functions with very large environments, like youtube.com, which has
environments with over 13K bindings, causing environment lookups to
take a noticeable amount of time, showing up high while profiling.
Adding a HashMap significantly increases performance on such websites.
(cherry picked from commit 78ecde9923e954e8ae9bb8d7a8ceefc08a8130ae)
This proposal has reached stage 4 and was merged into the ECMA-262 spec.
See: https://github.com/tc39/ecma262/commit/961f269
(cherry picked from commit 84ad36de0692b8890a2aa7ab66ed4d679cf630c8;
amended to replace one ASSERT() with VERIFY())
This proposal has reached stage 4 and was merged into the ECMA-262 spec.
See: https://github.com/tc39/ecma262/commit/d72630f
(cherry picked from commit 3aca12d2fadca1628a4dd2f800050b4e54194d65)
This implements the proposed update to the ShadowRealm proposal for
integrating the ShadowRealm specification into the web platform.
(cherry picked from commit d1fc76bffdafe5a057c0da5855d9d643608bd726)
This allows us to align our implementation in the same order as the
specification.
No functional change with the current implementation of this AO.
However, this change is required in order to correctly implement a
proposed update of the shadow realm proposal for integration with
the HTML spec host bindings in order to give the ShadowRealm
object the correct 'intrinsic' realm.
This is due to that proposed change adding a step which manipulates the
currently executing Javascript execution context, making the ordering
important.
(cherry picked from commit 0ec8af5b70702e9ee2edc7269c103fa49e6987c1)
We were storing these in Handle (strong GC roots) hanging off of
ECMAScriptFunctionObject which effectively turned into world leaks.
(cherry picked from commit 5aa1d7837fe37dd203763178df3325ff8b24abbd)
https://github.com/whatwg/console/pull/240 is an editorial change to use
the term "implementation-defined" more consistently. This seems to be
the only instance in the spec text which we quote verbatim.
(cherry picked from commit 51f82c1d939dd28a3e719d7fa495cf9f30d0921c)
Fixes a bug when "'Await' expression is not allowed in formal parameters
of an async function" is thrown for "await" encountered in a function
definition assigned to a default function parameter.
Fixes loading of https://excalidraw.com/
(cherry picked from commit 10064d0e1a89a4f48dc1e896de35a65f2ab946f4)
This didn't make any sense, and was already handled by pushing a new
execution context anyway.
By simply removing these bogus lines of code, we fix a bug where
throwing inside a function whose bytecode was shorter than the calling
function would crash trying to generate an Error stack trace (because
the bytecode offset we were trying to symbolicate was actually from
the longer caller function, and not valid in the callee function.)
This makes --log-all-js-exceptions less crash prone and more helpful.
(cherry picked from commit b3f77e47690cfd07058d824ea6f0b652489778bf)
This makes https://cling.com/ load, and more of the animated elements
on https://shopify.com/ start appearing.
(cherry picked from commit 0f9444fa06031e7d8e3c1ad36e701090e0b17ec1)
