Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
parens: Fix arrow-function bodies getting excess parens
We were inserting parentheses unnecessarily in the bodies of some arrow functions. In particular, `() => function(){}` would become `() => (function(){})`, and `() => class {}.foo.bar` would become `() => (class {}).foo.bar`. The cause turns out to be that we were taking the logic that applies if you have an *expression statement* starting with a FunctionExpression or ClassExpression -- which does indeed need parens, to avoid getting parsed as a FunctionDeclaration or ClassDeclaration respectively -- and applying it the same way if one of those expressions is instead at the start of a braceless arrow-function body, aka an ExpressionBody. In fact, while an ExpressionBody does call for similar intervention if it starts with a `{` token (so with an ObjectExpression node), that is the only case where it does. In the ES spec, this is expressed as lookahead constraints, on the one hand at ExpressionStatement: https://tc39.es/ecma262/#prod-ExpressionStatement and on the other hand at the two productions where ExpressionBody appears: https://tc39.es/ecma262/#prod-ConciseBody https://tc39.es/ecma262/#prod-AsyncConciseBody Adjust the logic accordingly to distinguish the two situations, and add tests. The ExpressionStatement lookahead constraints also point at one more edge case which we don't yet correctly handle. We'll fix that in the next commit for the sake of making the logic comprehensive, along with comments explaining how it corresponds to the spec. Fixes: benjamn#914 Fixes: benjamn#1082
- Loading branch information