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 bug with inferring bad arguments to overloads #5660

Merged
merged 2 commits into from Sep 24, 2018

Conversation

Projects
None yet
2 participants
@Michael0x2a
Collaborator

Michael0x2a commented Sep 22, 2018

Currently, it seems that when checking overloads, mypy starts by inferring the argument types in an empty context and swallows any errors generated in the process.

Mostly likely what the old overload implementation did next was recheck the arguments against the selected overload variant, regenerating any errors as necessary.

However, in the new overload implementation, it's unclear if we consistently do the same thing, mostly due to how we slice and dice the arguments to do things like union math.

This pull request does the low-effort thing and just removes the error suppression.

This pull request also does some unrelated clean-up -- apparently, the callee argument to 'infer_arg_types_in_context` is always 'None'.

Fixes #5659.

Fix bug with inferring bad arguments to overloads
Currently, it seems that when checking overloads, mypy starts by
inferring the argument types in an empty context and swallows any errors
generated in the process.

Mostly likely what the old overload implementation did next was recheck
the arguments against the selected overload variant, regenerating any
errors as necessary.

However, in the new overload implementation, it's unclear if we
consistently do the same thing, mostly due to how we slice and dice
the arguments to do things like union math.

This pull request does the low-effort thing and just removes the error
suppression.

This pull request also does some unrelated clean-up -- apparently, the
`callee` argument to 'infer_arg_types_in_context` is always 'None'.

Fixes #5659.
@Michael0x2a

This comment has been minimized.

Collaborator

Michael0x2a commented Sep 22, 2018

Note: I haven't tested this in our internal repos yet.

@ilevkivskyi

I think this is a correct fix. I have just few minor comments.

arg_types = self.infer_arg_types_in_context(None, args)
self.msg.enable_errors()
arg_types = self.infer_arg_types_in_empty_context(args)

This comment has been minimized.

@ilevkivskyi

ilevkivskyi Sep 22, 2018

Collaborator

At first I was sceptical about this, but after some thinking and playing it seems to me this is actually OK. Because under the hood all relevant possibilities (even the union math) go through infer_overload_return_type, that calls check_call with a CallableType item that, in turn, will trigger infer_arg_types_in_context using current matching overload item arg type as context. So it should be fine.

For example, if callee argument 2 has type List[int], infer the
argument expression with List[int] type context.
In short, we basically recurse on each argument without considering
in what context the argument was called.
"""
# TODO Always called with callee as None, i.e. empty context.

This comment has been minimized.

@ilevkivskyi

ilevkivskyi Sep 22, 2018

Collaborator

This TODO is now outdated.

foo(bar('lol').foo()) # E: Argument 1 to "bar" has incompatible type "str"; expected "int" \
# E: Item "int" of "Union[A, int]" has no attribute "foo"

This comment has been minimized.

@ilevkivskyi

ilevkivskyi Sep 22, 2018

Collaborator

I would add few tests about situations where absence of context can cause troubles (so that this will not regress). For example something like this:

def g(x: Optional[T] = None) -> List[T]: ...

@overload
def f(x: int) -> int: ...
@overload
def f(x: List[int]) -> List[int]: ...
def f(x):
    pass

reveal_type(f(g()))

I would also add something like

@overload
def g(x: List[str]) -> List[str]: ...
@overload
def g(x: List[int]) -> List[int]: ...
def g(x):
    pass

@overload
def f(x: int) -> int: ...
@overload
def f(x: List[int]) -> List[int]: ...
def f(x):
    pass

reveal_type(f(g([])))

but this one unfortunately causes an error both on master and with this PR. Probably this is something we should fix, but I am afraid this may depend on #4872 (but this is just a guess).

@Michael0x2a

This comment has been minimized.

Collaborator

Michael0x2a commented Sep 24, 2018

@ilevkivskyi (or maybe @msullivan?) -- this is ready for a second look whenever

@ilevkivskyi

Thanks! Looks good.

@Michael0x2a Michael0x2a merged commit b923c58 into python:master Sep 24, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@Michael0x2a Michael0x2a deleted the Michael0x2a:fix-bad-argument-inference-with-overloads branch Sep 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment