- Jan 23, 2019
-
-
jugglinmike authored
Previously, the early error prohibiting duplicate entries in UniqueFormalParameters was only tested in terms of async functions. In one case, this was misattributed to UniqeFormalParameters and only enforced for strict mode code. Extend coverage to the other function-creating productions which include UniqueFormalParameters (i.e. method definitions and non-async arrow functions), and update the existing tests to more accurately describe the source of the error.
-
- Oct 23, 2018
-
-
Mathias Bynens authored
-
Mathias Bynens authored
Closes #1634.
-
- Jan 05, 2018
-
-
Mike Pennisi authored
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.
-
- Jun 28, 2017
-
-
Mike Pennisi authored
This pattern makes expectations more explicit by making test files more literal.
-
- Apr 07, 2017
-
-
Leo Balter authored
After @rwaldron's feedback: The purpose of the `!` operator is to evaluate an UnaryExpression, coerce the result to a boolean value and then return the negated value of that operation. But that's not what you're trying to do at all—you just want to evaluate the expression to the right of the operator, nothing more, nothing less. In this specific case, you don't even really care about the evaluation, the goal is write valid (or invalid, as the case may be) syntax that is will be parsed according to a specific grammar rule that requires some operator to signal that the thing is an expression and not a Block Statement.
-
- Oct 19, 2016
-
-
Mike Pennisi authored
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'
-
- Jul 28, 2016
-
-
Brian Terlson authored
Closes #479
-