Skip to content

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

Merged
merged 6 commits into from
Jun 7, 2019

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.

@@ -20217,19 +20217,25 @@ namespace ts {
return checkPropertyAccessExpressionOrQualifiedName(node, node.left, node.right);
}

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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