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 :^)
The valid range for temporal values (`nsMinInstant`/`nsMaxInstant`)
means performing nanosecond-valued integers could lead to an overflow.
NB: Only the `roundingMode: "day"` case was affected, as all others were
already performing the division on floating-point `fractional_second`
values. I'm adding `.0` suffixes everywhere to make this fact clearer.
This adds a few local tests as well, as those are tested with sanitizers
enabled by default, unlike test262.
See 874ecf9
After this refactoring, we now correctly handle non-function /
non-undefined objects being passed multiple times: instead of skipping
assignment to promiseCapability altogether and failing with a
NotAFunction error in the end; on the second time the executor closure
is called, we return GetCapabilitiesExecutorCalledMultipleTimes.
This fixes the 7 `capability-executor-called-twice.js` test262 tests.
If an exception is thrown by FunctionDeclarationInstantiation for an
async or async-generator function, we still need to return a promise.
We can't just throw the exception.
81 new passes on test262. :^)
The exponent might be larger than the range of values representable by
an i32, so we have to use the `fmod` function instead of the modulo
operator.
This fixes 3 test262 tests on AArch64. No changes on x86-64.
This prototype is a bit tricky in that we need to maintain the iteration
state of the mapped iterator's inner iterator as we return values to the
caller. To do this, we create a FlatMapIterator helper to perform the
steps that apply to the current iteration state.
This uses a new Iterator type called IteratorHelper. This does not
implement IteratorHelper.prototype.return as that relies on generator
objects (i.e. the internal slots of JS::GeneratorObject), which are not
hooked up here.
Iterator.from creates an Iterator from either an existing iterator or
an iterator-like object. In the latter case, it sets the prototype of
the returned iterator to WrapForValidIteratorPrototype to wrap around
the iterator-like object's iteration methods.
This is in preparation for an upcoming implementation of the Iterator
Helpers proposal. That proposal will require a JS::Object type named
"Iterator", so this rename is to avoid conflicts.
Instead of assuming that there's an active AST interpreter, this code
now takes VM& everywhere and invokes the appropriate interpreter.
92 new passes on test262. :^)
