This PR proposes changes to existing test262 tests to allow them to pass under Hardened JavaScript (see Secure ECMAScript proposal and Hardened JavaScript). Moddable uses Hardened JavaScript for JavaScript runtimes on resource constrained embedded devices, including those targeted by ECMA-419.
The changes fall into four groups:
1. Replace use of new Date() with new Date(1970). Scripts running inside a Compartment cannot retrieve the current time, so new Date() throws but new Date(1970) succeeds. Very few tests need the current time, but instead simply need a Date instance.
2. Use Object.defineProperty instead of setting existing built-in properties directly, such as toString and toValue. In Hardened JavaScript, prototypes of built-in objects are frozen. Consequently, setting properties of an instance that exist on the prototype throw (Hardened JavaScript is always in strict mode).
3. Eliminate use of Math.random(). Scripts running inside a Compartment cannot generate random numbers. One test identified so far uses Math.random() in a way that can easily be replaced with a counter.
4. Narrow the scope of exception tests. Consider the following
assert.throws(TypeError, () => {
var s1 = new Date();
s1.toString = Boolean.prototype.toString;
s1.toString();
});
This test passes, but only because new Date() fails by throwing a TypeError. If the invocation of the Date constructor is resolved by (1) above, then the assignment to toString fails as per (2) above. The script should be modified as below to ensure that assert.throws only tests the intended statement, s1.toString(). The modified script tests the intended functionality and passes under Hardened JavaScript
var s1 = new Date(1970);
Object.defineProperty(s1, "toString", {
value: Boolean.prototype.toString
});
assert.throws(TypeError, () => {
s1.toString();
});
This is an initial PR to begin the process of adapting test262 for use with Hardened JavaScript. Further changes are expected, with the vast majority likely to fall into the four groups described above.
Thank you to gibson042, kriskowal, and erights for their advice on this work.
There is no such hidden constructor, it's the same as the hidden
AsyncFunction constructor. In other words:
```js
Object.getPrototypeOf(async () => {}).constructor ===
Object.getPrototypeOf(async function () {}).constructor
```
Also add a test to ensure that %AsyncFunction.prototype% is indeed the
prototype of an async arrow function.
Closes#4044.
* Update test for o[p] = f()
Update S11.13.1_A7_T3.js now that consensus has been reached on https://github.com/tc39/ecma262/pull/3307.
* Rename test and add an analogous one for super.
For the statement level test, the inner class name is not initialized
at the time the decorators evaluate, resulting in a ReferenceError
that the declaration can not be accessed prior to initialization.
Similar, non-decorator code, like:
class C {
static dec() {}
static {
this.x = C.dec();
class C {}
}
}
also results in a ReferenceError.
For the expression level test, the var C is undefined at the time the
decorators are evaluated, resulting in TypeError while trying to access
a member of undefined.
Similar, non-decorator code, like:
var C = class {
static f() {};
static {
this.x = C.f();
}
}
also results in a TypeError.
While we're at it, use assert() instead of assert.sameValue() for brevity,
if we are not specifically testing that the return value of hasOwnProperty
is the value true or false; and add more informative assertion messages to
help with debugging.
In some cases, the Object.hasOwnProperty.call could be replaced with
verifyProperty(), if the property descriptor was also being verified at
the same time.
This fixes some tests that were faulty to begin with: a common mistake was
Object.hasOwnProperty(obj, prop) which is probably going to return false
when that's not what you want.
The only instances left of `Object.hasOwnProperty` are one regression test
in implementation-contributed which I can't tell if it was intentionally
needed to trigger the regression, and a few instances of
`Object.hasOwnProperty('prototype')` which would defeat the purpose to
convert into `Object.prototype.hasOwnProperty.call(Object, 'prototype')`
form.
Closes: #3524
There were three things wrong with the 'and', 'or', and 'nullish' tests
that I added as part of #2940:
1. They were in the wrong folder (should be
expressions/logical-assignment, not expressions/compound-assignment)
2. The tests for ||= and ??= on readonly accessor properties were
incorrect. These assignments would short-circuit if the getter
returned 1 as it previously did, so PutValue would not throw.
3. The tests for ||= and ??= on private methods were invalid, as a
method always evaluates to true in a boolean context, and is not
nullish, so these would always short-circuit.
I've removed the invalid private method cases, fixed the readonly
accessor cases, and added new templates to test the short-circuit
behaviour as well as the non-short-circuit behaviour.
Closes: #3413
This tests compound assignment, with each compound assignment operator,
to each kind of private reference (private field, private accessor
property with getter and setter, private accessor property with only
getter, and private method). The latter two cannot be assigned to and
therefore throw.
Closes: #2940
The phase field must precede the type field for negative tests
to have a consistent style and be able to parse easier.
Related to the goal of https://github.com/tc39/test262/issues/1997
Added this check to the linting script and updated tests accordingly.
Some tests which include function declarations designed to verify
behavior do not reference those functions. Insert the references
necessary for those functions to serve their intended purpose.
This reverts commit b690cb67be9b487eb10156c03e2c00869e88cc9d, reversing
changes made to 50dd431dffe5cf86e9064a652d6b01dbbe542cf0. This is
necessary because the reverted changeset reduced coverage by an unknown
extent.
Prior to this commit, the modified tests used the strict equality
operator to compare computed values with negative zero. Due to the
semantics of that operator, these tests would spuriously pass if the
value under test was in fact positive zero.
Update the tests to be more precise by instead asserting equality with
the `assert.sameValue` utility method (since that method correctly
distinguishes between negative zero and positive zero).
Prior to this commit, the modified test included two different
expressions in positions that were meant to describe the same
expression. This meant that the value of the intended expression was
only partially verified.
Correct the test to fully verify the value of the expression.
