-
-
Notifications
You must be signed in to change notification settings - Fork 21.6k
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
Try to guess method return type even if subscript base has no value #84264
Try to guess method return type even if subscript base has no value #84264
Conversation
0cf0161
to
a055228
Compare
a055228
to
1d67e8f
Compare
91eeb90
to
69275e4
Compare
Rebased and added a test case |
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 approving on principle. Doing this speeds up... a general workflow where writing code faster is a priority and polishing it with static typing is an afterthought. In other words, it's just nice.
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.
Let's give this a try!
Might use a rebase though, there's been changes to the test suite in recent months so we should make sure it still works properly. |
69275e4
to
cb11ff2
Compare
cb11ff2
to
24912d2
Compare
Rebased and adjusted the test to account for #99102 |
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 haven't tested, but it makes sense to me.
Thanks! |
Fixes #78003.
We want to guess the method return type not only if the base has a reduced value but also if the base has a resolved type.
The following example shows the problem:
Since a has no value in the example, the autocompletion does not try to guess the type of
to_str(10)
.Note that we need to use internal classes to observe that this PR solves the problem. There are other problems preventing it to work in the context of #78003.