* 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.
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.
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'
* Assert creation of 'arguments' object
Ensure that the 'arguments' object is created in cases where it is not
required by the body but is required by the parameters.
* Add tests for cases that disable "arguments" map
* Add tests for NewTarget override of bound function
* Add test for properties of exotic String objects
The `negative` frontmatter tag expresses an expectation for the behavior
of the test file as a whole. The `assert.throws` helper function offers
more fine-grained control over expectations because it may be applied to
specific statements and expressions. This makes it preferable in cases
where it may be used (i.e. when the test body does not describe a syntax
error or early error).
Re-implement assertions for errors to use the `assert.throws` helper
function wherever possible.
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.
- Add missing "var" declarations and noStrict flags
- Add strict mode tests for:
- arguments-object/10.6-6-3 -> arguments-object/10.6-6-3-s
- arguments-object/10.6-6-4 -> arguments-object/10.6-6-4-s
- Remove try-finally clean-up code
- Add strict mode compatible tests for eval-code/S10.4.2_A1.1_T*
- No strict mode compatible files added for eval-code/S10.4.2_A1.2_T*, because it doesn't really make sense in this context.
- (S10.4.2_A1.1 and S10.4.2_A1.2 should probably be removed, because the tested behaviour is not required by the spec.)
- Split S8.5_A10, S8.5_A4 and S8.1_A3 into declaration (both modes) and assignment tests (non-strict only)
Part of issue #35.
These tests are derived from the following files within the Google V8
project:
test/mjsunit/es6/typed-array-iterator.js
test/mjsunit/es6/arguments-iterator.js
test/mjsunit/es6/string-iterator.js
test/mjsunit/es6/collection-iterator.js
André Bargull
Rick Waldron
Alexey Shvayka
jugglinmike
Mathias Bynens
Leo Balter
Caio Lima
Kevin Gibbons
Brian Terlson
Brian Terlson