Skip to content
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

mypy sometimes ignores type errors inside calls to overloaded functions #5659

Closed
msullivan opened this issue Sep 21, 2018 · 1 comment
Closed
Labels

Comments

@msullivan
Copy link
Collaborator

In the following program:

from typing import Union, Iterable, Tuple

class A:
    def foo(self) -> Iterable[Tuple[int, int]]: pass

def bar(x: int) -> Union[A, int]: ...

list(bar('lol').foo())  # No errors!
dict(bar('lol').foo())  # No errors!

tuple(bar('lol').foo())  # Does error
set(bar('lol').foo())  # Does error

two errors ought to be generated for each call (one for int not having .foo, one for 'lol' being the wrong type of argument). These errors seem to be suppressed while checking list and dict, which get filled with Anys.

@msullivan msullivan added bug mypy got something wrong priority-0-high labels Sep 21, 2018
@msullivan
Copy link
Collaborator Author

msullivan commented Sep 21, 2018

This looks like an overloads issue. The following doesn't produce any errors:

from typing import Union, Iterable, Tuple, TypeVar, Generic, overload, Any

class A:
    def foo(self) -> Iterable[Tuple[int, int]]: pass

def bar(x: int) -> Union[A, int]: ...

_T = TypeVar('_T')

@overload
def foo() -> None: ...
@overload
def foo(iterable: Iterable[_T]) -> None: ...

def foo(iterable: Any = None) -> None: pass

foo(bar('lol').foo())  # No errors!

This is a regression from 0.610 to 0.620 (I haven't dug any deeper than that.)

@Michael0x2a thoughts?

@msullivan msullivan changed the title mypy ignores type errors inside list and dict calls mypy sometimes ignores type errors inside calls to overloaded functions Sep 22, 2018
Michael0x2a added a commit to Michael0x2a/mypy that referenced this issue 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 python#5659.
Michael0x2a added a commit that referenced this issue Sep 24, 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants