-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Fix captured shorthand properties in ES2015 loops #59285
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 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'm not particularly worried about the perf - I think I only even used getSymbolAtLocation
over getResolvedSymbol
because a previous WIP version passed in non-identifier nodes (or I was explicitly looking for the ignoreErrors
flag because at the time of it being very WIP, I needed it to cut down on the error diff).
The isExpressionNode
change is the one that's a bit more iffy, since it'll affect other callsites (like the type baselines), but if that ends up having weird knock-on effects we can't predict, we can always undo that part and put an exception into the condition in checkSingleIdentifier
specifically (since that's the place we definitely need it to behave like this). But @rbuckton might have more opinions on that, and weather the { name }
in a shorthand property should truly count as an expression or not.
@typescript-bot test it |
Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
Hey @jakebailey, the results of running the DT tests are ready. Everything looks the same! |
@jakebailey Here are the results of running the user tests with tsc comparing Everything looks good! |
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
Preemptively sending this just so we don't forget: @typescript-bot cherry-pick this to release-5.5 |
Hey, @jakebailey! I've created #59288 for you. |
@jakebailey Here are the results of running the top 400 repos with tsc comparing Everything looks good! |
…e-5.5 (#59288) Co-authored-by: Jake Bailey <[email protected]>
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.
There are quite a few types baseline changes that seem like an unintentional consequence of considering the name
of a shorthand assignment as an expression.
tests/baselines/reference/shorthandOfExportedEntity02_targetES5_CommonJS.types
Outdated
Show resolved
Hide resolved
…i...) into release-5.5 (microsoft#59288)" This reverts commit 6c7df1f.
function isExpressionNodeOrShorthandPropertyAssignmentName(node: Identifier) { | ||
// TODO(jakebailey): Just use isExpressionNode once that considers these identifiers to be expressions. | ||
return isExpressionNode(node) | ||
|| isShorthandPropertyAssignment(node.parent) && (node.parent.objectAssignmentInitializer ?? node.parent.name) === node; |
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.
Here's the targeted fix.
@@ -3550,6 +3550,7 @@ export function isInExpressionContext(node: Node): boolean { | |||
case SyntaxKind.ExpressionWithTypeArguments: | |||
return (parent as ExpressionWithTypeArguments).expression === node && !isPartOfTypeNode(parent); | |||
case SyntaxKind.ShorthandPropertyAssignment: | |||
// TODO(jakebailey): it's possible that node could be the name, too |
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 plan to follow-up on this after merging; hoping that it's straightforwad to fix getTypeAtLocation to retain its old behavior.
@typescript-bot cherry-pick this to release-5.5 |
Hey, @jakebailey! I've created #59307 for you. |
…e-5.5 (#59307) Co-authored-by: Jake Bailey <[email protected]>
Fixes #59262
Two problems:
isInExpressionContext
(and by extensionisExpressionNode
) didn't consider the case of "name only" object prop shorthand. This meant we weren't even walking into the shorthand in this example.Fixing this caused knock-on effects in some baselines, but I'm not sure any are actually a problem.They areThen, we were using
getSymbolAtLocation
to get the node for the shorthand prop, but that ended up returning the wrong symbol; we want the one for the "value side" of the prop. Switching togetResolvedSymbol
(same as the other caller ofcheckIdentifierCalculateNodeCheckFlags
) seems to fix that.Not 100% certain if this makes perf bad, though. I assume not given we already had to call the same symbol stuff via
getSymbolAtLocation
.