The RegExpBuiltinExec internal operation was modified in March of 2016
[1]: instead of referencing the `global` and `sticky` properties of the
"this" value, the algorithm now infers those values from the object's
[[OriginalFlags]] internal slot.
This change invalidated a number of tests. In cases where the change
resulted in an observable behavior, update the tests to assert the
latest specification text. In cases where the change removed a
previously-observable behavior, remove the files completely.
Specification text change set:
> 1. Assert: Type(_S_) is String.
> 1. Let _length_ be the number of code units in _S_.
> 1. Let _lastIndex_ be ? ToLength(? Get(_R_, `"lastIndex"`)).
> - 1. Let _global_ be ToBoolean(? Get(_R_, `"global"`)).
> - 1. Let _sticky_ be ToBoolean(? Get(_R_, `"sticky"`)).
> + 1. Let _flags_ be the value of _R_'s [[OriginalFlags]] internal slot.
> + 1. If _flags_ contains `"g"`, let _global_ be *true*, else let _global_ be *false*.
> + 1. If _flags_ contains `"y"`, let _sticky_ be *true*, else let _sticky_ be *false*.
> 1. If _global_ is *false* and _sticky_ is *false*, let _lastIndex_ be 0.
> 1. Let _matcher_ be the value of _R_'s [[RegExpMatcher]] internal slot.
> - 1. Let _flags_ be the value of _R_'s [[OriginalFlags]] internal slot.
> 1. If _flags_ contains `"u"`, let _fullUnicode_ be *true*, else let _fullUnicode_ be *false*.
> 1. Let _matchSucceeded_ be *false*.
> 1. Repeat, while _matchSucceeded_ is *false*
[1] https://github.com/tc39/ecma262/pull/494
This change set does not include a test for restrictions relating to
template literals because such a test already exists in the project.
While a form of this test for string literals in strict mode code
existed previously, it is less precise and relies on unrelated
semantics. Remove the previous form and replace with a more direct
version.
Assert the expected behavior of the ArraySpeciesCreate abstract
operation in the 5 Array instance methods from which it is invoked.
This change set does not include tests for ECMAScript realm
considerations because Test262 does not currently expose a mechanism for
interfacing with realms.
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).
Leo Balter
Mike Pennisi
Ian Halliday
Gorkem Yakin
Brian Terlson