You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The second line will be interpreted as a division expression, but it should actually be a regexp literal. The reason for this is that arrow function literals are in a weird place in the grammar — in AssignmentExpression, “below” the comma operator but “above” most other binary operators.
The existing behavior is correct for the two following examples:
x=>x
/a/g;
(x=>{})
/a/g;
This bug is obscure and unlikely to come up in practice, and several other parsers get it wrong too. And I suspect that fixing it might add more complexity than it's worth. But it is a bug, so here's a bug report.
The text was updated successfully, but these errors were encountered:
From #1600.
Simple example:
The second line will be interpreted as a division expression, but it should actually be a regexp literal. The reason for this is that arrow function literals are in a weird place in the grammar — in
AssignmentExpression
, “below” the comma operator but “above” most other binary operators.The existing behavior is correct for the two following examples:
This bug is obscure and unlikely to come up in practice, and several other parsers get it wrong too. And I suspect that fixing it might add more complexity than it's worth. But it is a bug, so here's a bug report.
The text was updated successfully, but these errors were encountered: