We were implicitly converting the throw completion's value into a normal
completion in `AsyncFunctionDriverWrapper::continue_async_execution`,
which meant the routine generated by `generate_await` didn't know that
the value had to be thrown when execution resumed.
Without this change, we mistakenly pass 13 tests for `Array.fromAsync`,
which we do not implement yet. But even with that "regression", we pass
17 more test262 tests in total.
When someone calls PrimitiveString::utf16_string() on a rope string,
we know for sure that the client wants a UTF-16 string and may not
be interested in a UTF-8 version at all.
To avoid round-tripping through UTF-8 in this scenario, callers can
now inform resolve_rope_if_needed() about their preferred encoding,
should rope resolution take place. The UTF-16 case is actually a lot
simpler than the UTF-8 case, since we can simply ask for UTF-16 data
for each fiber of the rope, and then concatenate all the fibers.
Since LibJS always uses UTF-16 for regular expression matching, this
avoids round-tripping through UTF-8 whenever the input to a regex test
is already UTF-16. :^)
This optimization was no longer helpful after the bug fix for missing
invalidation on global delete was introduced in 331f6a9e6, since we
now have to check bindings for presence in the global environment every
time anyway.
Since the bytecode VM now has fast GetGlobal in most cases, let's not
even worry about this and just remove the unhelpful "optimization".
In fact, removing this is actually an *optimization*, since we avoid
a redundant has_binding() check on every global variable access. :^)
This counter is incremented whenever a mutating operation occurs
within the environment's set of bindings.
It is going to be used by GetGlobal instruction to correctly invalidate
cache when global declarative environment is mutated.
Cell::heap() and Cell::vm() needed to access member functions from
HeapBlock, and wanted to be inline, so they were moved to VM.h.
That approach will no longer work with VM.h not being included in every
file (starting from the next commit), so this commit fixes that circular
import issue by introducing secondary base classes to host the
references to Heap and VM, respectively.
Since we can't rely on shape identity (i.e its pointer address) for
unique shapes, give them a serial number that increments whenever a
mutation occurs.
Inline caches can then compare this serial number against what they
have seen before.
This function now takes an optional out parameter for callers who would
like to what kind of property we ended up getting.
This will be used to implement inline caching for property lookups.
Also, to prepare for adding more forms of caching, the out parameter
is a struct CacheablePropertyMetadata rather than just an offset. :^)
Previously, the usage of local variables was limited for all function
declarations. This change relaxes the restriction and only prohibits
locals for hoistable annexB declarations.
This change fixes an issue where identifiers used in default function
parameters were being "registered" in the function's parent scope
instead of its own scope. This bug resulted in incorrectly detected
local variables. (Variables used in the default function parameter
expression should be considered 'captured by nested function'.)
To resolve this issue, the function scope is now created before parsing
function parameters. Since function parameters can no longer be passed
in the constructor, a setter function has been introduced to set them
later, when they are ready.
Since AST interpreter switches to bytecode to execute generator
functions, arguments stored in local variables always need to be
initialized for such functions.
Using local variables to store function parameters makes Kraken tests
run 7-10% faster.
For now this optimization is limited to only be applied if:
- Parameter does not use destructuring assignment
- None of the function params has default value
- There is no access to "arguments" variable inside function body
This is (part of) a normative change in the ECMA-262 spec. See:
d09532c
We recently implemented other parts of that commit in LibJS, but missed
this change:
442ca4f9b42b19d1b5ab
These are not strictly unresolvable references. Treating them as such
fails an assertion in the `delete UnaryExpression` semantic (which is
Reference::delete_ in our implementation) - we enter the unresolvable,
branch, which then asserts that the [[Strict]] slot of the reference is
false.
This is part of an old normative change that happened soon after
Andreas made `super` closer to spec in 1270df2.
See https://github.com/tc39/ecma262/pull/2267/
This was introduced into bytecode by virtue of copy and paste :^)
Bytecode results:
Summary:
Diff Tests:
+2 ✅ -2 ❌
- Update ECMAScriptFunctionObject::function_declaration_instantiation
to initialize local variables
- Introduce GetLocal, SetLocal, TypeofLocal that will be used to
operate on local variables.
- Update bytecode generator to emit instructions for local variables
Now ExecutionContext has vector of values that will represent values
of local variables.
This vector is initialized in ECMAScriptFunctionObject::internal_call()
or ECMAScriptFunctionObject::internal_const() using number of local
variables provided to ECMAScriptFunctionObject by the parser.
Saving vector of local variables names in ECMAScriptFunctionObject
will allow to get a name by index in case message of ReferenceError
needs to contain a variable name.
ECMA-262 implies that `MIN_VALUE` should be a denormalized value if
denormal arithmetic is supported. This is the case on x86-64 and AArch64
using standard GCC/Clang compilation settings.
test262 checks whether `Number.MIN_VALUE / 2.0` is equal to 0, which
only holds if `MIN_VALUE` is the smallest denormalized value.
This commit renames the existing `NumericLimits<FloatingPoint>::min()`
to `min_normal()` and adds a `min_denormal()` method to force users to
explicitly think about which one is appropriate for their use case. We
shouldn't follow the STL's confusingly designed interface in this
regard.
Since the relationship between VM and Bytecode::Interpreter is now
clear, we can have VM ask the Interpreter for roots in the GC marking
pass. This avoids having to register and unregister handles and
MarkedVectors over and over.
Since GeneratorObject can also own a RegisterWindow, we share the code
in a RegisterWindow::visit_edges() helper.
~4% speed-up on Kraken/stanford-crypto-ccm.js :^)
