Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encode expected error "phase" #778

Merged
merged 10 commits into from
Oct 20, 2016
Merged

Conversation

jugglinmike
Copy link
Contributor

I have rebased the patch previously submitted at gh-655. Please refer to that
pull request for motivation, design discussion, and suggestions for merging
strategy. This version applies the patterns established there; it contains no
substantial changes other than updating the error format of recently-introduced
tests.

I have verified the validity of the change set by running the tests in a recent
build of V8, first on Test262's master branch and then on this branch. The
reported errors are almost identical; this factoring happens to catch a handful
of additional violations in that runtime:

  • language/literals/regexp/invalid-braced-quantifier-exact.js
  • language/literals/regexp/invalid-braced-quantifier-lower.js
  • language/literals/regexp/invalid-braced-quantifier-range.js
  • language/literals/regexp/u-dec-esc.js
  • language/literals/regexp/u-invalid-class-escape.js
  • language/literals/regexp/u-invalid-extended-pattern-char.js
  • language/literals/regexp/u-invalid-identity-escape.js
  • language/literals/regexp/u-invalid-legacy-octal-escape.js
  • language/literals/regexp/u-invalid-non-empty-class-ranges-no-dash-a.js
  • language/literals/regexp/u-invalid-non-empty-class-ranges-no-dash-ab.js
  • language/literals/regexp/u-invalid-non-empty-class-ranges-no-dash-b.js
  • language/literals/regexp/u-invalid-non-empty-class-ranges.js
  • language/literals/regexp/u-invalid-oob-decimal-escape.js
  • language/literals/regexp/u-invalid-quantifiable-assertion.js
  • language/literals/regexp/u-unicode-esc-bounds.js
  • language/literals/regexp/u-unicode-esc-non-hex.js

...all of these owe to the same basic flaw, which is well-known to the V8 team:
https://bugs.chromium.org/p/v8/issues/detail?id=896

@tcare @leobalter I would like to avoid having to rebase this work a third
time--if at all possible, can you please prioritize review? Thank you!

Improve test consistency by using the `assert.throws` helper function to
assert runtime exceptions. Remove superfluous code.
These tests specifically concern error produced from the global scope,
precluding the use of the `assert.throws` helper function.
The expected errors in these tests cannot be asserted with the
`assert.throws` helper function for various reasons. Re-format their
meta-data according to the latest design in order to more precisely
describe test expectations.
Extend the test generation tool to emit the recently-modified format of
the "negative" meta-data. Update the effected test case files
accordingly.
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'
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.
@tcare
Copy link
Member

tcare commented Oct 19, 2016

Looks good!

Thanks so much for rebasing and breaking down the commits so they are easy to read and review!

@leobalter leobalter merged commit 638c480 into tc39:master Oct 20, 2016
@leobalter
Copy link
Member

LGTM

@jugglinmike
Copy link
Contributor Author

Thank you both!!

jugglinmike added a commit to jugglinmike/test262-harness that referenced this pull request Jun 30, 2017
In October of 2016, the frontmatter format of Test262 tests was updated
to include more information about expected errors [1]. Prior to that
change, the `negative` attribute was defined as a regular expression
that matched the expected error's `name` attribute. Following that
change, the `negative` attribute is defined as a dictionary containing
`phase` and `type` attributes. The `type` attribute is a string value
describing the expected error's `name` attribute.

Update the validation logic to interpret the meta data according to this
new format.

[1] tc39/test262#778
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants