The tests for the parsing of various statement were expressed using
eval. This made the tests more complex than necessary and also prevented
the tests from providing value to ECMAScript parsers.
Remove the use of eval and instead express the expectations with literal
source text. Rename the files to make each test's purpose more clear.
Early errors may result from parsing the source text of a test file, but
they may also result from parsing some other source text as referenced
through the ES2015 module syntax. The latter form of early error is not
necessarily detectable by ECMAScript parsers, however. Because of this,
the label "early" is not sufficiently precise for all Test262 consumers
to correctly interpret all tests.
Update the "phase" name of "early" to "parse" for all those negative
tests that describe errors resulting from parsing of the file's source
text directly. A forthcoming commit will update the remaining tests to
use a "phase" name that is more specific to module resolution.
Authored via the following command:
$ find test -type f -print0 | \
xargs -0 sed \
-i 's/^\(\s*\)negative:\s*SyntaxError\s*$/\1negative:\n\1 phase: early\n\1 type: SyntaxError/g'
Add tests that assert the management of the running execution context's
LexicalEnvironment and VariableEnvironment components, as created by the
following abstract operations:
- NewDeclarativeEnvironment
- NewObjectEnvironment
- NewFunctionEnvironment
Many tests require the use of non-strict direct eval, meaning they may
not be run in strict mode. This does not effect coverage because the
semantics in these cases are not observable from strict mode code.
Some situations require the creation of a binding, but this binding has
no relevance to the test itself. In these cases, use names consisting
solely of the underscore character (`_`).
Avoid the use of Block statements wherever possible, as these trigger
the creation of additional environments which may interfere with the
behavior under test.
ECMAScript 2015 introduced tail call optimization for function calls
occuring in a number of positions in the grammar. Assert expected
behavior by triggering a large (but configurable) number of recursive
function calls in these positions. Compliant runtimes will execute such
programs without error; non-compliant runtimes are expected to fail
these tests by throwing an error or crashing when system resources are
exhausted.
The `$PRINT` helper function has no effect on test behavior. The
following tests use it to report assertion outcomes (and as a result
will fail silently):
- test/language/function-code/S10.2.1_A4_T2.js
- test/language/function-code/S10.2.1_A5.1_T1.js
- test/language/function-code/S10.2.1_A5.1_T2.js
- test/language/function-code/S10.2.1_A5.2_T1.js
Remove the function definition and all references within tests. Update
tests that use it as an error reporting mechanism to instead use an
appropriate `assert` helper function.
In neglecting to assert the type of error thrown (or that any error was
thrown at all), these tests cannot fail. Refactor the tests to use the
`assert.throws` helper method, which takes these details into
consideration.
Mike Pennisi
Leo Balter
Rick Waldron
Mathias Bynens
André Bargull
Brian Terlson