Fix excess parens on awaits

[KernelDeimos]

recast doesn't do what it says on the tin: preserve the formatting of the code. Any code using async and await syntax is very unlikely to be rendered the same coming out of recast as it went in.

On this PR, @techLeadGuy suggested removing the AwaitExpression case in needsParens(). This worked for me. Maybe it works in all cases, but I'm not 100% sure. I think it's worth making this change to bring recast closer to its goal, and people like me should be expected to try and improve recast if our code breaks.

[KernelDeimos]

I'm starting to realize this sucks just a little bit more than I previously thought. The babel parser indeed does not care to express the information about whether or not parens were included originally. The parser is lossy, except for when the tokens option is set, 'cause then it gives a nice little

17058       "type": {$
17059         "label": "(",$
17060         "beforeExpr": true,$
17061         "startsExpr": true,$
17062         "rightAssociative": false,$
17063         "isLoop": false,$
17064         "isAssign": false,$
17065         "prefix": false,$
17066         "postfix": false,$
17067         "binop": null,$
17068         "updateContext": null$
17069       },$

Separately though - it looks like you get lexer output pasted at the end of the AST. I don't understand why we can't just have a CST-producing parser that supports modern javascript but :shrug:

[KernelDeimos]

Closing this because it won't work

[eventualbuddha]

I don't understand why we can't just have a CST-producing parser that supports modern javascript.

While everyone surely has their own reasons, I am less interested in this than I once was because of Prettier. As long as Recast can parse the code and preserve formatting ~95% while producing valid JS syntax, then for my use cases (codemods) it’s fine. This isn’t good enough for all use cases such as IDE integration with running something on save, though.