* Re-organize coverage for YieldExpression
* Extend test coverge for YieldExpression
* fixup! Extend test coverge for YieldExpression
Remove unused variables
A recent change to the specification [1] introduces parse-time errors
for certain usages of `super` within eval code. Modify all tests that
are affected by this change:
- Update the test bodies to accurately enforce the new semantics
- Rename files to better reflect the section of the specification that
they enforce
- Update test meta-data
- Change the `esid` meta-data to reflect the location of the relevant
specification text
- Remove the `es6id` meta-data as the behavior is no longer relatable
to that specification
- Introduce the `features` meta-data in cases where the test file's
new location no longer reflects all required language features
[1] "Normative: Clarify rules around super inside eval"
https://github.com/tc39/ecma262/pull/685
* Add tests for prototype realm inference
* Add tests for miscellaneous realm concerns
* Add tests for realm of spec-created Errors
In some cases, Error objects produced by the specification are
observable from ECMAScript code. Among these cases, some are further
differentiated in that they occur outside of any built-in function and
may be triggered through syntactic production directly. The current
realm record is commonly interpreted incorrectly under these
circumstances.
Add tests asserting that the expected realm record is used when
constructing such Error objects.
* Add tests for realm use in ArraySpeciesCreate
* Add tests for function realm retrieval
* Add tests for cross-realm behaviors of Symbols
* Add tests for GetValue and PutValue
* Add tests for realm of spec-created Arrays
In some cases, Arrays produced by CreateArrayFromList are observable
from ECMAScript code. Among these cases, two occur outside of any
built-in function and may be triggered through syntactic production
directly. The current realm record is commonly interpreted incorrectly
under these circumstances.
Add tests asserting that the expected realm record is used when
constructing arrays.
* Add test for spec-created object
* fixup! Add tests for realm of spec-created Errors
* fixup! Add tests for realm of spec-created Errors
* fixup! Add tests for prototype realm inference
* fixup! Add tests for miscellaneous realm concerns
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'
This test is being added because the committee is considering changing
this evaluation order (as discussed at the May 2016 Munich meeting). The
consequences of this spec change will be more clear as a test change
than a simple test addition.
* 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
* Add tests for early errors in functions
* Improve tests for class accessors
Use the `propertyHelper.js` utility in order to functionally test the
property descriptors of class methods.
* Remove redundant tests
The semantics of an IdentifierReference as a PropertyDefinition within
an object initializer are exhaustively tested by the files in this
directory whose name match the pattern `prop-def-id-*.js`.
Delete the redundant tests in favor of the more descriptively-named and
more exhaustive alternatives.
* Rename tests
* Update test names to be more descriptive
* Add tests for property descriptors of accessors
* Add tests for runtime error during method dfn
* Add test for observable iteration
* 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 is a pure miscellaneous change to use global values of NaN and Infinity instead of their namespaced equivalents.
Ref 9ae0567a50 (r69049894)
cc @suwc
This re-factors some existing Sputnik tests to be more targeted and to use a
pattern that can be generalized to other forms. We could test these all day,
but I've limited myself to forms introduced in ES2015, specifically
YieldExpression and new.target. Note that SpiderMonkey incorrectly throws a
SyntaxError for these.
I thoughtlessly wrote ReferenceError tests for yield = 1 until I realized
that such productions are not actually recognized by the grammar, so the early
errors do not apply. Instead, I've added a negative syntax test for that case.
* Refactor test for valid cover
* Add tests for ValidSimpleAssignmentTarget
Ensure that constructs introduced in ES2015 are disallowed as assignment
targets, with or without a "cover" grammar.
* Add test for grammar precedence of YieldExpression
* Add missing test for early error
* Add missing test for WithBaseObject
* Improve coverage for `new.target`
* Add test for deletion of SuperReference
* Add tests for `in` keyword restrictions
* fixup! Improve coverage for `new.target`
The global isNaN is not precise at all, and Number.isNaN is an ES6 feature that makes it preferrable to use assert's sameValue for NaN values, as it handles it internally using the comparison.
* Improve test coverage for `super` keyword
Add tests for SuperCall and SuperProperty, organized together in the
`test/language/expressions/super/` directory. For SuperProperty, include
tests for usage from within Object initializers and class bodies because
a different set of semantics are observable from each context.
Utilize the test generation tool to increase coverage of destructuring
assignment semantics. Previously, only destructuring assignment in the
AssignmentExpression position was tested. With this change applied, the
same tests will assert expected behavior for destructuring assignment in
`for..of` statements, as well.
A limited number of tests are applied to the `for..in` statement as
well, but due to the iteration protocol observed by that statement, many
destructuring tests are not relevant, and others cannot be automatically
generated from this format.
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.
Closes#572
Introduce tests for new semantics for ES2015 features such as
lexically-scoped bindings. Also add tests for semantics defined in prior
editions of the specification but not yet covered in this test suite.
Limit tests in `language/expressions/call/` and `built-ins/eval/` to
only assert details that are directly related to the invocation pattern.
Re-organize all other tests within the `language/eval-code/` directory,
further categorizing each as `direct` or `indirect` as appropriate.
Remove the extraneous "executable" flag from those files which carried
it.
This harness function is not necessary in the majority of cases in which
it is used. Remove its usage to simplify tests and decrease the amount
of domain-specific knowledge necessary to contribute to the test suite.
Persist the harness function itself for use by future tests for ES2015
modules (such a helper is necessary for tests that are interpreted as
module code).
Except for a small set of expected input/output pairs, both ES5 and
ES2015 define the expected return value of these methods in terms of an
"implementation-dependent approximation." This makes it inappropriate to
enforce expectations for specific values, even if expressed imprecisely.
jugglinmike
Tim Disney
Michael Ficarra
Brian Terlson
Jeff Morrison
Leo Balter
Mathias Bynens
Ian Halliday
Gorkem Yakin