* Add tests for "Class Static Init. Blocks" proposal
This proposal is currently at "stage 3" in TC39's standardization
process.
* fixup! Add tests for "Class Static Init. Blocks" proposal
* Correct identifier reference
* Update tests for grammar
* Update tests for identifiers
* Add tests for scope derivation
This behavior is covered by another test in this directory:
`arguments-strict-single.js`. Although the syntax error happens to occur
within the body of a function expression, this distinction is not
significant enough to warrant the test's presence nor does it motivate
the introduction of many similar negative syntax tests which are
currently unavailable.
The tests for the parsing of variable declarations 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.
The tests for the parsing of `for/in` loops 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. Move the tests to the `for-in` directory to better reflect
the grammar production that they test.
Two tests placed within the "variable" directory do not include a variable
declaration. Because the behavior they assert is covered by an existing
test (test/language/arguments-object/10.5-1gs.js), they may be removed
without reducing coverage.
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.
A number of tests for the parsing of the AssignmentExpression production
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` in the relevant tests and instead express the
expectations with literal source text. Remove superfluous "onlyStrict"
restriction from tests by declaring the probe binding prior to
assignment.
Because expectations regarding error "phase" are now expressed via test
meta-data, the test runner may now enforce this requirement on negative
tests.
Remove the "NotEarlyError" from the project source. This reduces the
amount of domain knowledge required to author tests and lessens the
potential for inconsistencies between tests.
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'
* Extend tests for class "name" inference
Ensure that when a class defines a static "name" method, that method
definition prevents the "name" inference behavior.
* Re-generate tests
This change set includes tests for most invocations of the
SetFunctionName abstract operation in the ES2015 specification.
Practical testing considerations preclude the introduction of tests for
certain invocations:
- The project is still vetting methods to sustainably test the semantics
of the Destructuring Binding pattern across all valid productions.
- 13.3.3.6 Runtime Semantics: IteratorBindingInitialization
- 13.3.3.7 Runtime Semantics: KeyedBindingInitialization
- Without a loader, there is no way to access a function object declared
in an ExportDeclaration, so `name` assignment cannot be tested in
these cases
- 14.1.19 Runtime Semantics: InstantiateFunctionObject
- 14.4.12 Runtime Semantics: InstantiateFunctionObject
- 14.5.15 Runtime Semantics: BindingClassDeclarationEvaluation
- 15.2.3.11 Runtime Semantics: Evaluation
Some tests specifically concern the application of the `use strict`
directive as it appears in JavaScript source code. These tests should
*not* be run with the `onlyStrict` flag because relying on the test
runner to enable strict mode makes the semantics of the source code
irrelevant. Update these tests to use the `noStrict` flag.
Other tests concern language semantics that are only valid in strict
mode, but the mechanism for enabling strictness is inconseqential.
Update these tests to use the `onlyStrict` flag and remove any redundant
`use strict` directive prologues contained within.
Still other tests are valid both within and outside of strict mode.
In keeping with the majority of other tests, do not specify any
restrictions on the environments in which these tests may be run.
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.
Add missing variable declarations (issue #35)
Split S12.6.3_A10 and S12.6.3_A10.1 because both files seem to test implicit global variables (issue #35)
Changes (issue #35)
- Add missing noStrict flags.
- Change 13.2-15-1 and 13.2-18-1 to use assert.js and propertyHelper.js (simplifies writable and configurable checks while in strict mode).
- Add variable declarations for globals.
- Create copies of S13.2.1_A6_T1 and S13.2.1_A6_T2 instead of adding variable declarations, because both files seem to test implicit global variables.
- Split S13_A14 and S13_A16 to work in strict mode.
- Remove assignment to .name property.
Add missing noStrict flags (issue #35)
Add missing noStrict flags and variable declarations (issue #35)
Add missing noStrict flags (issue #35)
André Bargull
rwaldron
jugglinmike
Alexey Shvayka
Leo Balter
Mathias Bynens
Tom Care