CharacterRange abstract operation tests should be phase: runtime and not phase: early #1193
Description
The Early Errors rule for regular expression literals states that the literals must be parsed using the Pattern goal symbol of the regular expression grammar. This might trigger early SyntaxErrors when the regular expression in the literal is malformed. However, there are some "malformed" regular expressions which still pass the grammar and its early errors conditions, e.g. /[\s-\d]/u, where the bounds of a character range are character sets, not single characters. Such expressions also lead to SyntaxErrors, but only during the evaluation of the regular expression literal, when interpreting the pattern as a RegExpMatcher using the Pattern Semantics.
Therefore, I believe the tests in the following files to be incorrect as of their current state:
- u-invalid-non-empty-class-ranges.js
- u-invalid-non-empty-class-ranges-no-dash-a.js
- u-invalid-non-empty-class-ranges-no-dash-b.js
- u-invalid-non-empty-class-ranges-no-dash-ab.js
The phase of the SyntaxError should be runtime instead of early and therefore they shouldn't be prefixed with the throw statements. The RegExp validation is performed in Runtime Semantics: Character Range and not in Static Semantics.
NB: In ES5.1, SyntaxErrors thrown by the runtime semantics of constructing a RegExp object actually did cause early errors, but this behaviour disappeared from the spec in ES6.
NB2: These tests contradict the test built-ins/RegExp/property-escapes/character-class.js), in which the regular expression literal /[\p{Hex}-\uFFFF]/u is expected to throw a SyntaxError at runtime.