-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Fix internal crash when resolve same partial type twice #14552
Conversation
This comment has been minimized.
This comment has been minimized.
test-data/unit/check-inference.test
Outdated
arr = [] | ||
arr.append(arr.append(1)) | ||
[out] | ||
main:3: error: "List[int]" has no attribute "append" |
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.
It's better than a crash (thanks for filing this PR!), but this error still doesn't make sense.
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.
@JelleZijlstra You are right, that is because I forgot to add fixtures to a test. Fixed, please, review again.
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.
Thanks! I guess when there's something weird going on in a mypy test there's a 90% chance it's due to a fixture.
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
Fixes: python#14548 Fixed case when untyped list item type resolving can lead to an internal crash. Code to reproduce this issue: ```py arr = [] arr.append(arr.append(1)) ``` Basically, the issue is that after the first resolving of `arr.append` method, `var` is deleted from `partial_types`, and as war as `arr.append` is a nested call we try to delete the same `var` that was already deleted.
#14552) (#14553) Fixes: #14548 Fixed case when untyped list item type resolving can lead to an internal crash. Code to reproduce this issue: ```py arr = [] arr.append(arr.append(1)) ``` Basically, the issue is that after the first resolving of `arr.append` method, `var` is deleted from `partial_types`, and as war as `arr.append` is a nested call we try to delete the same `var` that was already deleted. Co-authored-by: Yurii Karabas <1998uriyyo@gmail.com>
Fixes: #14548
Fixed case when untyped list item type resolving can lead to an internal crash.
Code to reproduce this issue:
Basically, the issue is that after the first resolving of
arr.append
method,var
is deleted frompartial_types
, and as war asarr.append
is a nested call we try to delete the samevar
that was already deleted.