While adding spec comments to PerformEval, I noticed we were missing
multiple steps.
Namely, these were:
- Checking if the host will allow us to compile the string
(allowing LibWeb to perform CSP for eval)
- The parser's initial state depending on the environment around us
on direct eval:
- Allowing new.target via eval in functions
- Allowing super calls and super properties via eval in classes
- Disallowing the use of the arguments object in class field
initializers at eval's parse time
- Setting ScriptOrModule of eval's execution context
The spec allows us to apply the additional parsing steps in any order.
The method I have gone with is passing in a struct to the parser's
constructor, which overrides the parser's initial state to (dis)allow
the things stated above from the get-go.
The spec notes that this AO is unused by ECMA-262, but is provided for
ECMAScript hosts. Move the definition to a common location to allow
test-js to also use it.
Previously this would've said `make_handle(Value(1234))` is null, as it
did not contain a cell (but rather a plain Value), which made throwing
primitives spin forever in BC mode.
This is an editorial change in the Intl spec. See:
087995c233d29c
This also adds a missing spec link for the sanctioned units and fixes a
broken spec link for IsSanctionedSingleUnitIdentifier. In LibUnicode,
the NumberFormat generator is updated to use the constexpr helper to
retrieve sanctioned units.
This commit upstreams most of the C++ bits of the LibJS test262 runner
at https://github.com/linusg/libjs-test262/, specifically everything but
the main.cpp file serving as the actual executable.
Since all of these are just regular JS objects, I opted to put them in
LibJS itself, in a new Contrib/ directory like many other projects have
one. Other code that can end up there in the future is the runtime for
esvu, which might even share some functionality with test262's $262
object.
The code has been copied verbatim, and only a small number of changes
have been made:
- Putting everything into the JS::Test262 namespace
- Removing now redundant JS namespace prefixes
- Updating includes to use absolute <LibJS/...> paths
- Updating the SPDX-License-Identifier comments from MIT to BSD-2-Clause
I gained permission to change the license and upstream these changes
from all the major contributors to this code: Ali, Andrew, David, Idan.
The removal of the code from the source repository is here:
https://github.com/linusg/libjs-test262/pull/54
This is only the first step, the goal is to eventually upstream the
actual libjs-test262-runner executable and supporting Python scripts
into SerenityOS as well.
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
`delete` has to operate directly on Reference Records, so this
introduces a new set of operations called DeleteByValue, DeleteVariable
and DeleteById. They operate similarly to their Get counterparts,
except they end in creating a (temporary) Reference and calling delete_
on it.
When calling emit_load_from_reference with a MemberExpression, it is
only necessary to store the result of evaluating MemberExpression's
object when performing computed property lookup.
This allows us to skip unnecessary stores for identifier lookup.
For example, this would generate 3 unnecessary stores:
```
> Temporal.PlainDateTime.prototype.add
JS::Bytecode::Executable (REPL)
1:
[ 0] GetVariable 0 (Temporal)
[ 28] Store $2
[ 30] GetById 1 (PlainDateTime)
[ 40] Store $3
[ 48] GetById 2 (prototype)
[ 58] Store $4
[ 60] GetById 3 (add)
```
With this, it generates:
```
> Temporal.PlainDateTime.prototype.add
JS::Bytecode::Executable (REPL)
1:
[ 0] GetVariable 0 (Temporal)
[ 28] GetById 1 (PlainDateTime)
[ 38] GetById 2 (prototype)
[ 48] GetById 3 (add)
```
The body of for/in/of can contain an unconditional block terminator
(e.g. return, throw), so we have to check for that before generating
the Jump to the loop update block.
