Skip to content

Conversation

@ahejlsberg
Copy link
Member

@ahejlsberg ahejlsberg commented Jun 6, 2019

With this PR, in a property access obj.x or element access obj["x"] we widen obj 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 widen obj in an element access, which was inconsistent.

Fixes #31728.
Fixes #31762.

@ahejlsberg
Copy link
Member Author

@typescript-bot run dt
@typescript-bot test this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 6, 2019

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
Copy link
Collaborator

typescript-bot commented Jun 6, 2019

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.

}

function isMethodAccessForCall(node: Node) {
while (node.parent.kind === SyntaxKind.ParenthesizedExpression) {
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

@sandersn sandersn left a 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.

@ahejlsberg
Copy link
Member Author

@typescript-bot test this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 7, 2019

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.

@ahejlsberg
Copy link
Member Author

@typescript-bot test this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 7, 2019

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.

@ahejlsberg
Copy link
Member Author

@typescript-bot test this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 7, 2019

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.

@ahejlsberg ahejlsberg merged commit 8705844 into master Jun 7, 2019
@ahejlsberg ahejlsberg deleted the wideningInAccessExpressions branch June 7, 2019 19:46
@microsoft microsoft locked as resolved and limited conversation to collaborators Oct 21, 2025
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.

#31711 breaks assignability Strange error involving evolving array type and Array#sort callback

4 participants