[JavaScript] Obscure quirk with binary operators after arrow function body

[Thom1729]

First reported in #1600.

Example:

a=>{}
/a/; // Should be a regex literal, but highlighted like a division expression

Explanation from the linked issue:

… Arrow function expressions are specified strangely in the formal grammar so that if the ConciseBody is an AssignmentExpression, operators other than the comma operator will bind tightly within that expression. When the body is a block, this has the side effect of forbidding certain constructs involving operators on arrow functions. The core Sublime syntax does not account for this, instead treating arrow functions like PrimaryExpressions. …

This is a fixable bug. It is not related to the arrow function parameter list issue; the existing fallthrough logic for arrow function parameter lists misparsed as parenthesized expressions works just fine. The problem begins after the block. If the arrow function were a PrimaryExpression, then the subsequent slash would denote a division operator, but because of the unique way in which arrow functions are specified a division operator would be invalid, and so the ASI algorithm inserts a semicolon immediately before the slash, which is of course then parsed as the beginning of a regular expression literal.

This isn't a high-priority issue due to the obscurity of the bug. For reference, several dedicated JavaScript parsers seem to get this wrong. It probably should be fixed eventually, though.