-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Consistent widening in access expressions #31802
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
@typescript-bot run dt |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 1aed26a. You can monitor the build here. It should now contribute to this PR's status checks. |
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at 1aed26a. You can monitor the build here. It should now contribute to this PR's status checks. |
@@ -20217,19 +20217,25 @@ namespace ts { | |||
return checkPropertyAccessExpressionOrQualifiedName(node, node.left, node.right); | |||
} | |||
|
|||
function isMethodAccessForCall(node: Node) { | |||
while (node.parent.kind === SyntaxKind.ParenthesizedExpression) { |
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.
This should probably? also skip both kinds of casts.
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.
No, if there is an intervening type assertion then that specifies the type and widening isn't relevant.
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 think this is a good fix, but I'm worried that we need a bigger rethinking of widening at some point. Right now the rules are getting to be a complex patchwork that is hard to explain.
@typescript-bot test this |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 1aed26a. You can monitor the build here. It should now contribute to this PR's status checks. |
@typescript-bot test this |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 69706bd. You can monitor the build here. It should now contribute to this PR's status checks. |
@typescript-bot test this |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 4856768. You can monitor the build here. It should now contribute to this PR's status checks. |
With this PR, in a property access
obj.x
or element accessobj["x"]
we widenobj
when the property or element access is (a) the target of an assignment, or (b) a method access in a call expression (i.e. the this of the call). These are the situations in which we are mutating (or possibly mutating) the object and therefore should widen its type.Previously we'd always widen
obj
in a property access and never widenobj
in an element access, which was inconsistent.Fixes #31728.
Fixes #31762.