* 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
* Remove duplicate test
The behavior under test is verified by another file in Test262:
test/language/expressions/compound-assignment/S11.13.2_A2.1_T3.3.js
That version is preferable because it does not depend on `eval` and
because it supports both strict and non-strict mode.
* Remove overly-permissive test
By asserting only the presence of an "own" property, this test can be
satisfied from both strict mode code and non-strict mode code.
The following test verifies the presence of the "own" property and the
associated descriptor's values in strict mode:
test/language/arguments-object/10.6-13-c-3-s.js
That subsumes the semantics verified by this test, making it
superfluous. Remove the test.
* Remove overly-permissive test
By asserting only the absence of a syntax error, this test can be
satisfied from both strict mode code and non-strict mode code.
The following test verifies the runtime behavior of accessing the
property in strict mode code:
test/language/arguments-object/10.6-13-c-1-s.js
That subsumes the semantics verified by this test, making it
superfluous. Remove the test.
* Remove duplicate test
The behavior under test is verified by another file in Test262:
test/built-ins/Math/prop-desc.js
That version is preferable because it follows the test suite's
convention for testing property descriptors and because it supports both
strict and non-strict mode.
* Remove duplicate test
The behavior under test is verified by two separate files:
test/language/statements/function/line-terminator-non-strict.js
test/language/statements/function/line-terminator-strict.js
These files differ only in their usage of the `noStrict`/`onlyStrict`
metadata. Because tests are intended to be interpreted in both modes by
default, these can be expressed with a single file that does not limit
the permissible modes.
A number of tests for the parsing of function literals 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.
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.
The templates are being used for many tests reusing the same available function forms.
The format they are provided allow us to extend tests with cases for other tests relying
in the same formats.
André Bargull
Youssef Soliman
rwaldron
jugglinmike
Alexey Shvayka
Valerie Young
Shu-yu Guo
Leo Balter
Shu-yu Guo
Richard Gibson
Adrian Heine
Mathias Bynens
Yusuke Suzuki
Joseph Pecoraro