Skip to content

Conversation

@jridgewell
Copy link
Contributor

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 needsParens would 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.

  • I’ve added tests to confirm my change works.
  • (If the change is user-facing) I’ve added my changes to changelog_unreleased/*/pr-XXXX.md file following changelog_unreleased/TEMPLATE.md.
  • I’ve read the contributing guidelines.

Try the playground for this PR


// 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
Copy link
Member

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.

Copy link
Contributor Author

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?

@thorn0
Copy link
Member

thorn0 commented Mar 17, 2020

Please target the next branch, not master.

@jridgewell jridgewell changed the base branch from master to next March 18, 2020 06:36
@jridgewell jridgewell force-pushed the closure-type-casts-3 branch from b53b5ec to ab0273b Compare March 18, 2020 06:44
@jridgewell jridgewell force-pushed the closure-type-casts-3 branch from ab0273b to a977fe6 Compare March 18, 2020 06:51
@jridgewell
Copy link
Contributor Author

Please target the next branch, not master.

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.
Copy link
Member

@thorn0 thorn0 Mar 18, 2020

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

@jridgewell
Copy link
Contributor Author

Closing for #7791.

@jridgewell jridgewell closed this Mar 19, 2020
@jridgewell jridgewell deleted the closure-type-casts-3 branch March 19, 2020 03:25
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JSDoc typedef parentheses are removed if member access is done on a typedef'd object variable

2 participants