The tests for the parsing of variable declarations 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.
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.
Two tests placed within the "variable" directory do not include a variable
declaration. Because the behavior they assert is covered by an existing
test (test/language/arguments-object/10.5-1gs.js), they may be removed
without reducing coverage.
- Add cases for invalid syntax
- Add valid cases
- nested imports
- add non existent file case
- Fix cases and templates to use a full importcall expr token
- add case for call expression position
- remove unnecessary module flag from templates
- Add templates for nested with
The tests for the parsing of postfix increment, postfix decrement,
prefix increment, and prefix decrement 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.
Additionally removed the `arrow-function` feature for
test/language/eval-code/direct/new.target-fn.js as it is not testing
arrow-functions, but they are mentioned in the preamble.
Thsi test for the parsing of string literals was expressed using `eval`.
This made the test more complex than necessary and also prevented the
test from providing value to ECMAScript parsers.
Remove the use of `eval` and instead express the expectation with
literal source text.
This test is technically valid because it does trigger a SyntaxError in
conforming runtimes. However, it was authored and documented to test
LegacyOctalEscapeSequence, but due to an apparent typo, it actually
demonstrates an unrelated parsing error.
Because 'legacy-octal-escape-sequence-stricts.js' sufficiently tests the
restriction on LegacyOctalEscapeSequence, remove this test rather than
correct it.
This test for string literals asserts the restriction on
LegacyOctalEscapeSequence in strict mode. It is not sufficiently
distinct from the test 'legacy-octal-escape-sequence-stricts.js' to
warrant inclusion in the test suite. Because that test includes much
more thorough documentation, it should be preferred.
A number of tests for string literals assert the restriction on
LegacyOctalEscapeSequence in strict mode code and differ only in the
escape sequence under test. Although each is valid, none of the escape
sequences are sufficiently distinct from the test
'legacy-octal-escape-sequence-stricts.js' to warrant their inclusion in
the test suite. Because that test's use of literal code makes it
consumable by parsers and because that test includes much more thorough
documentation, it should be preferred.
Summary of LegacyOctalEscapeSequences under test in the removed files:
test/language/literals/string/7.8.4-10-s.js: eval('var x = " \\10 ";');
test/language/literals/string/7.8.4-11-s.js: eval('var x = "\\16";');
test/language/literals/string/7.8.4-12-s.js: eval('var x = "\\17";');
test/language/literals/string/7.8.4-13-s.js: eval('var x = "\\30";');
test/language/literals/string/7.8.4-14-s.js: eval('var x = "\\31";');
test/language/literals/string/7.8.4-15-s.js: eval('var x = "\\37";');
test/language/literals/string/7.8.4-16-s.js: eval('var x = "\\400";');
test/language/literals/string/7.8.4-17-s.js: eval('var x = "\\411";');
test/language/literals/string/7.8.4-18-s.js: eval('var x = "\\43a";');
test/language/literals/string/7.8.4-19-s.js: eval('var x = "\\463";');
test/language/literals/string/7.8.4-2-s.js: eval('var x = "\\1";');
test/language/literals/string/7.8.4-20-s.js: eval('var x = "\\474";');
test/language/literals/string/7.8.4-21-s.js: eval('var x = "\\77";');
test/language/literals/string/7.8.4-22-s.js: eval('var x = "\\777";');
test/language/literals/string/7.8.4-23-s.js: eval('var x = "\\000";');
test/language/literals/string/7.8.4-24-s.js: eval('var x = "\\001";');
test/language/literals/string/7.8.4-25-s.js: eval('var x = "\\106";');
test/language/literals/string/7.8.4-26-s.js: eval('var x = "\\207";');
test/language/literals/string/7.8.4-27-s.js: eval('var x = "\\377";');
test/language/literals/string/7.8.4-28-s.js: eval('var x = "\\376";');
test/language/literals/string/7.8.4-29-s.js: eval('var x = "\\3760";');
test/language/literals/string/7.8.4-3-s.js: eval('var x = "a\\4";');
test/language/literals/string/7.8.4-32-s.js: eval('var x = "\\1\\1";');
test/language/literals/string/7.8.4-33-s.js: eval('var x = "\\1\\2\\7";');
test/language/literals/string/7.8.4-4-s.js: eval('var x = "z\\7";');
test/language/literals/string/7.8.4-5-s.js: eval('var x = "\\00a";');
test/language/literals/string/7.8.4-6-s.js: eval('var x = "\\01z";');
test/language/literals/string/7.8.4-7-s.js: eval('var x = "a\\03z";');
test/language/literals/string/7.8.4-8-s.js: eval('var x = " \\06";');
Test262 already includes tests to ensure the correct runtime semantics
for these forms. Add equivalent tests designed to verify that the
equivalent parsing behavior is also observed.
Verify runtime semantics through assignment to an unresolvable
reference, reducing the complexity of tests that previously relied on
the semantics of the `eval` function.
Because these files contain syntax errors, the code they contain is not
intended to be executed, and the runtime semantics are therefore
irrelevant. Simplify the files by removing the unnecessary code.
- "CannotSuspendMainAgent" feature was changed to "CanBlockIsFalse" flag
- Move annex-b tests into annex-b directory
- Update variable names in nonshared-int-views.js tests
- Move getReport() call in nan-for-timeout.js to avoid iloop
- Update BigInt constructor to match new semantics (tc39/proposal-bigint#138)
- Tests that lookahead and lookbehind are not extended to
QuantifiableAssertion, as in https://github.com/tc39/ecma262/pull/1102
- Additional tests verifying some more combinations of cases for
QuantifiableAssertion being invalid in Unicode mode.
Based on the tests in https://chromium-review.googlesource.com/c/v8/v8/+/926102
These tests pass on V8 (if the throw for early errors is removed to
work around a V8 issue where RegExps don't have early errors).
* Test for change to cache templates by site, not contents
These tests are against a specification change based on discussion in
https://github.com/tc39/ecma262/issues/840
The tests here passed on SpiderMonkey but failed on other
implementations, which implement the current specification.
* Add a test that caching is by source location, not function identity
* Update existing tests to reference the spec properly
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.
A number of tests for the parsing of object initializers 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.
A number of tests for the parsing of the DeleteExpression production
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. Remove superfluous tests which
only differed in the runtime semantics of source text that could not be
evaluated due to syntax errors.
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.
Static fields were broken up from instance fields and demoted to
Stage 2 in the November 2017 TC39 meeting. This patch removes the
test262 tests which test static class fields.
A number of tests for the parsing of the AssignmentExpression production
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. Remove superfluous "onlyStrict"
restriction from tests by declaring the probe binding prior to
assignment.
A few BigInt tests had a blank line in an inconvenient place which
breaks an old, possibly incorrect YAML parser used by V8's test262
test automation. The best fix is to deploy a new YAML parser, but
in the short term, this patch deletes the blank lines and lets
V8 understand the feature flags below. Related: #1370
* Accessing `ta[0]` throws a TypeError.
* Fix array indices starting at 0 and property references
* Fix classfields templates for properly checking static propnames.
* Generate tests
* `assert.equal` is not defined
* Add missing includes
* Generate tests
* typo s/Avalue/42/
* fix whitespace
* Add missing var for strict mode
* Expand generated class fields tests for forbidden computed property name values
Ref https://github.com/tc39/test262/pull/1339#issuecomment-342830243
* derived classes have access to private names in base classes, if private names are in scope