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.
Except for a small set of expected input/output pairs, both ES5 and
ES2015 define the expected return value of these methods in terms of an
"implementation-dependent approximation." This makes it inappropriate to
enforce expectations for specific values, even if expressed imprecisely.
- Add missing noStrict flags when tests explicitly require non-strict semantics (e.g. unqualified delete, with statement)
- Change `throw new Exception(...)` to `$ERROR(...)` in call/*
- Replace dynamic strict mode check with noStrict flag in call/11.2.3-3_8
- Align assignment/11.13.1_A3.1 with 11.13.1_A3.2 to avoid creating implicit global variable
- Split test into multiple files when undeclared variable are under test
- addition/S11.6.1_A2.4_T3
- division/11.5.2_A2.4_T3
- does-not-equals/11.9.2_A2.4_T3
- equals/S11.9.1_A2.4_T3
- greater-than/S11.8.2_A2.4_T3
- greater-than-or-equal/S11.8.4_A2.4_T3
- in/S11.8.7_A2.4_T3
- instanceof/11.8.6_A2.4_T3
- left-shift/S11.7.1_A2.4_T3
- less-than/S11.8.1_A2.4_T3
- less-than-or-equal/S11.8.3_A2.4_T3
- modulus/S11.5.3_A2.4_T3
- multiplication/11.5.1_A2.4_T3
- right-shift/11.7.2_A2.4_T3
- strict-does-not-equals/11.9.5_A2.4_T3
- strict-equals/11.9.4_A2.4_T3
- subtraction/11.6.2_A2.4_T3
- unsigned-right-shift/11.7.3_A2.4_T3
- Add declaration when implicit global variable creation not part of the test
- assignment/11.13.1_A4_T1
- compound-assignment/S11.13.2_A3.1_T*
- compound-assignment/S11.13.2_A3.2_T*
- grouping/11.1.6_A3_T5
- instanceof/S15.3.5.3_*
- Split test into multiple files when unqualified delete is used
- delete/S11.4.1_A2.2_T1.js
- delete/11.4.1_A3.2
- grouping/S11.1.6_A2
- grouping/S11.1.6_A3_T6
