These tests are ostensibly designed to validate parsing of Regular
Expression literals--specifically those which use Unicode escape
sequences to declare flags. However, because the syntax is expressed in
terms of a string literal and then evaluated dynamically, the escape
sequences in use have no bearing on the program code which is ultimately
parsed. These tests therefore do not extend coverage in any meaningful
way and may be removed.
The tests for the parsing of literal values 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. Rename the files to make each test's purpose more clear.
The production under test is also used in the following file:
test/language/literals/numeric/legacy-octal-integer-strict.js
That test expresses the syntax with literal source text, making it
useful for parsers. Remove this test in favor of the other.
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";');
- 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).
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.
Ross Kirsling
Alexey Shvayka
Tooru Fujisawa
Leo Balter
Mike Pennisi
Kevin Gibbons
Rick Waldron
Mathias Bynens
Richard Gibson
Steve Fink
Daniel Ehrenberg
Valerie
André Bargull