As originally written, this test would spuriously pass when the deleted
property was incorrectly visited by enumation but correctly removed from
the object. In such cases, the accumulator string would take the form
"aa1baundefinedca3"
And satisfy all conditions intended to highlight implementation errors.
Refactor the test to avoid false negative by using an object with a null
prototype and verifying the exact contents of the accumulator string.
As originally written, this test would spuriously pass when the deleted
property was incorrectly visited by enumation but correctly removed from
the object. In such cases, the accumulator string would take the form
"aa1baundefinedca3"
And satisfy all conditions intended to highlight implementation errors.
Refactor the test to avoid false negative by using an object with a null
prototype and verifying the exact contents of the accumulator string.
* Add EnumerateObjectProperties tests for builtins which use it
* Add tests for EnumerateObjectProperties for for-in
* Add feature flag for for-in-order
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.
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'
This test was intended to assert the semantics of the `for-in`
statement, but it was mistakenly authored to use a `for-of` statement.
Update the statement under test, and improve the testing methodology to
correctly assert the creation of distinct bindings.
Ensure that early errors restricting labelled function declarations
within WithStatement and IfStatement are honored. Rename existing tests
to match the specification's spelling.
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.
- Prefix file names to explicitly describe the "head" position
- Remove statement name suffix as this information is reflected by each
file's location within the file hierarchy
In order to facilitate proper tail calls, ES2015 modified the completion
value of a number of statements.
These tests use `eval` to verify the new values.
Although the `for..in` statement allows Expressions to define the
iterator, only an AssignmentExpression may occupy this position in the
`for..of` statement.
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.
These tests are derived from the following files within the Google V8 project:
test/mjsunit/es6/regress/regress-2506.js
test/mjsunit/es6/regress/regress-3426.js
test/mjsunit/es6/regress/regress-3683.js
This change adds 'var' declarations for global variables to allow the tests to run in strict mode (see issue #35).
Extra care was taken to ensure the changes do not alter the test behavior, for example when implicit creation of global variables are part of the test.
Note: The change does not fix all strict mode errors due to missing 'var' declarations.
Keith Miller
rwaldron
Mike Pennisi
Alexey Shvayka
Kevin Gibbons
Gus Caplan
Ross Kirsling
Leo Balter
Mathias Bynens
André Bargull
Brian Terlson