The JS::VM now owns the one Bytecode::Interpreter. We no longer have
multiple bytecode interpreters, and there is no concept of a "current"
bytecode interpreter.
If you ask for VM::bytecode_interpreter_if_exists(), it will return null
if we're not running the program in "bytecode enabled" mode.
If you ask for VM::bytecode_interpreter(), it will return a bytecode
interpreter in all modes. This is used for situations where even the AST
interpreter switches to bytecode mode (generators, etc.)
The intent of the spec is that the output of console.dir is interactable
within the console. Our Printer implementation currently just prints the
provided object as a string, and doesn't check the provided `options`
argument. But having console.dir defined prevents exceptions from being
thrown on real websites.
Many operations in JavaScript may incur side effects, including calling
arbitrary user code. Since the user code will clobber the accumulator,
we have to take care to extract anything we need from the accumulator
before doing anything that may have side effects.
Fixes 3 test262 tests. :^)
The fix for this was to port the "don't create unnecessary FooObject
for property access on primitives" optimization from Reference,
which also brings us the correct behavior.
Since we no longer need to create or leave var environments directly
in bytecode, we can streamline the two instructions by making them
always operate on the lexical environment.
Instead of implementing this AO in bytecode, we now have an instruction
for it that simply invokes the C++ implementation.
This allows us to simplify Bytecode::Generator quite a bit by removing
all the variable scope tracking.
Don't try to implement this AO in bytecode. Instead, the bytecode
Interpreter class now has a run() API with the same inputs as the AST
interpreter. It sets up the necessary environments etc, including
invoking the GlobalDeclarationInstantiation AO.
Instead of trying to implement this AO in bytecode, we can just let it
be a C++ thing. Once we implement fast uncaptured locals, we won't even
be calling it super often.
Note that this does not change cycle-detection.
This is also was an unnecessary copy, since there is an easier, less
memory-intense way to do cycle detection than copying the entire
visited_set all the time.
In GlobalEnvironment::get_binding_value(), we can avoid an extra walk
of the declarative environment record if has_binding() returns a
cacheable environment coordinate.
Most JS::Objects don't have lazily-allocated intrinsic properties,
so let's avoid doing hash lookups by putting a flag on JS::Object that
tells us whether it's present in s_intrinsics.
Takes CPU time spent in those hash lookups from 1-2.5% to nothing on
various JS heavy pages.
Previously we were unable to parse code like `yield/2` because `/2`
was parsed as a regex. At the same time `for (a in / b/)` was parsed
as a division.
This is solved by defaulting to division in the lexer, but calling
`force_slash_as_regex()` from the parser whenever an IdentifierName
is parsed as a ReservedWord.
