Repository navigation
Infer better type for call to overload with Any actual arguments - #3917
Conversation
If the overload return type is ambiguous and there is an `Any` actual argument that seems to cause the ambiguity, infer `Any` as the type of the call expression instead of some precise type. Previously we sometimes inferred a precise type even though the type was ambiguous, resulting in false positives. This is not quite the most correct implementation since we sometimes incorrectly assume ambiguity caused by `Any` even though none actually exists. This is acceptable since this only affects calls with `Any` arguments that are imprecise anyway. Also, the correct logic would be quite complex, hard to test and probably not worth it, at least right now. Fixes #3662.
|
Somehow it seems to me that inferring the widest return type (if there is one) instead of |
| for item in items | ||
| ] | ||
|
|
||
| for i, arg_type in enumerate(arg_types): |
There was a problem hiding this comment.
It is quite hard to follow the logic in this place, maybe you could use something like act_pos, form_pos instead of i, j?
| reveal_type(f(1, a, a)) # E: Revealed type is 'builtins.int' | ||
| reveal_type(f('', a, a)) # E: Revealed type is 'builtins.object' | ||
| # Like above, but use keyword arguments. | ||
| reveal_type(f(y=1, z='', x=a)) # E: Revealed type is 'Any' |
There was a problem hiding this comment.
I would add one more test where the order of arguments is shuffled, just to be sure that the matching logic works right.
There was a problem hiding this comment.
Added another call where arguments are shuffled
|
The widest type may also generate false positives, since the wider type may be missing some attributes defined in the narrower type. Also, if a user creates an invariant container such as a list based on the result, it won't be compatible if the expected type is the narrower one. |
Yes, this is more important that contravariant, since invariant containers are abundant. |
|
OK, now we can go with #3300 |
2 participants
If the overload return type is ambiguous and there is an
Anyactualargument that seems to cause the ambiguity, infer
Anyas the type ofthe call expression instead of some precise type. Previously we
sometimes inferred a precise type even though the type was ambiguous,
resulting in false positives.
This is not quite the most correct implementation since we sometimes
incorrectly assume ambiguity caused by
Anyeven though none actuallyexists. This is acceptable since this only affects calls with
Anyarguments that are imprecise anyway. Also, the correct logic would be
quite complex, hard to test and probably not worth it, at least right
now.
Fixes #3662.