-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Fix printing of nested closure typecasts #7782
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
||
| // There's an annoying issue if both our node contains a typecast, and this | ||
| // ancestor contains a typecast. Unfortunately, both comments are applied | ||
| // to ancestor. So we need to detect this situation, and insert hack paren |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, we can't rely on what node the comment will be attached to. It's not always the ancestor. E.g. see #7775.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, I see. This is attaching two casts onto the same expression. I can fix this in a follow up PR using the same paren comment hack, if you'd like?
|
Please target the |
b53b5ec to
ab0273b
Compare
ab0273b to
a977fe6
Compare
Done. |
| function getParenStart(node) { | ||
| // Closure typecast comments only really make sense when _not_ using | ||
| // typescript or flow parsers, so we take advantage of the babel parser's | ||
| // parenthesized expressions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot this feature was Babel-only. We should use Babel's createParenthesizedExpressions option then. This should give us nested parens in the AST. Could you look into that? Okay, I'm looking into that. #7791
|
Closing for #7791. |
Fixes #6122.
This goes through the rather complicated steps to determine when parens surround a typecast comment, including when both the node and the ancestor have typecasts.
I had to add really hacky comment nodes in order to insert the parens in the correct locations. This is because using the normal
needsParenswould insert multiple typecasts comments before the first(. It order to get it right, we need to print the first typecast, then the first(, then the next typecast, so on. I was only able to get it right by splicing the comments in.changelog_unreleased/*/pr-XXXX.mdfile followingchangelog_unreleased/TEMPLATE.md.✨Try the playground for this PR✨