Parsing or pre-parsing regexps must detect and throw the syntax error.

This bug report is still valid; /(/ is not detected during parsing (or preparsing).

So for example this parses fine:

function test() { /(/.test("("); } 

Reassigning generic parsing bugs to rossberg@.

 Issue 3384  has been merged into this issue.

Reassigning to mathias@, do you perhaps have any insight here? V8 seems to be in clear spec violation regarding regexp early errors, but as far as I'm aware there are no plans to change this.

 Issue chromium:746942  has been merged into this issue.

I had heard this was all a question of performance. From an eshost test, it seems like other JS implementations may be checking these things in the preparser, unlike V8 (though maybe I'm being overly optimistic about what's lazily parsed). If an efficient RegExp validator can be implemented in parser-base.cc, that would be nice.

My understanding is that detecting these errors early in V8 would have too much of a negative performance impact for relatively little gain. Unless someone comes up with an efficient way of validating RegExps during parsing, this is unlikely to change.

Some questions I still have: is swapping early errors for runtime errors an acceptable spec deviation? What about new proposals such as Unicode property escapes? Those early errors are runtime errors in V8. Should that block shipping? Should the spec proposal be updated accordingly, knowing that it would be inconsistent with the rest of the language?

Looks like Scanner::ScanRegExpPattern is pretty simple; it just collects ( and ) among other chars and doesn't do anything specific for them.

Depending on what errors we want to recognize, it might not be that costly. E.g., making it track ( and ) and see if they match sounds pretty simple - probably collecting the chars into the buffer dominates.

However, it's still extra work... Dunno.

There's a whole section of failing test262 tests that covers this; it's definitely a lot more than just matching parens. Some examples:

/?/
/{2}/
/{2,3}/
/\u{110000}/u
/\8/u

Though interestingly, even engines that throw early errors for regexps don't get all these right.

Ref. https://github.com/tc39/ecma262/pull/984

FWIW V8 already implements the #984 PR--at the moment that RegExps are parsed and compiled, those sorts of errors are thrown. V8 doesn't implement the old specification, which would throw a SyntaxError when the part of the RegExp is actually dynamically reached by executing on a string.