--disallow-untyped-calls allows calling values with Any type

[JukkaL]

The calls to f and ff below aren't rejected when using --disallow-untyped-calls, even though I believe that they should be:

from typing import Any

from non_existent import f  # type: ignore  # Not in the build

def g(): pass

def h() -> None:
    g(asdf=1)  # Error: Call to untyped function "g" in typed context
    f(asdf=1)  # No error reported, but this is untyped
    ff: Any
    ff()  # No error reported, and again this in untyped

At the very least the first call should probably be caught. If non_existent gets added in the build with no type annotations, it would start generating errors. However, I'd expect that adding a module to the build should result in fewer Any-related errors, not more.

Marking this a high priority since I've been bit by this twice in production code.

[JukkaL]

Tagging as a usability bug since this can be a major distraction in annotation workflows.

[onlined]

I'm working on a solution, but doing this results in self-check failure. I investigated the cause: The failure happens because some functions are annotated with return type Any, and when the return values are called or their methods are called, it causes "Call to untyped function", naturally. @JukkaL How can we solve this?

[JukkaL]

@onlined What about useing # type: ignore? How many failures are there?

[onlined]

There are 244 failures.

[JukkaL]

Can you give some examples? If there are that many failures, # type: ignore is probably not the best way to move forward.

[onlined]

These are some of the failures:

mypy/test/data.py:66: error: Call to untyped function "join" in typed context
mypy/test/data.py:74: error: Call to untyped function "join" in typed context
mypy/test/data.py:77: error: Call to untyped function "join" in typed context
mypy/test/data.py:77: error: Call to untyped function "read" in typed context
mypy/test/data.py:81: error: Call to untyped function "join" in typed context
mypy/test/data.py:83: error: Call to untyped function "join" in typed context
mypy/test/data.py:83: error: Call to untyped function "read" in typed context
mypy/test/data.py:87: error: Call to untyped function "strip" in typed context
mypy/test/data.py:87: error: Call to untyped function "split" in typed context
mypy/test/data.py:92: error: Call to untyped function "strip" in typed context
mypy/test/data.py:92: error: Call to untyped function "split" in typed context
mypy/test/data.py:97: error: Call to untyped function "strip" in typed context
mypy/test/data.py:97: error: Call to untyped function "split" in typed context
mypy/test/data.py:104: error: Call to untyped function "group" in typed context
mypy/test/data.py:106: error: Call to untyped function "join" in typed context

[onlined]

@JukkaL What should we do about this?

[JukkaL]

I sampled a few and these don't look like calls to untyped functions. In some cases the callee has an overloaded type, and in another case it was a union of callables. All of these seemed valid for --disallow-untyped-calls. I wonder if there are issues with your implementation? You can use reveal_type to display the inferred type of the called function.

[onlined]

Yes, now I realize that it's my fault. I am working on it!

[onlined]

I reduced it to 137 failures, they are related to lack of information in the stubs. For example:

mypy/git.py:41: error: Call to untyped function "splitlines" in typed context
mypy/git.py:44: error: Call to untyped function "split" in typed context
mypy/git.py:45: error: Call to untyped function "decode" in typed context
mypy/git.py:50: error: Call to untyped function "strip" in typed context
mypy/git.py:55: error: Call to untyped function "strip" in typed context
mypy/git.py:57: error: Call to untyped function "split" in typed context
mypy/git.py:63: error: Call to untyped function "strip" in typed context
mypy/git.py:69: error: Call to untyped function "strip" in typed context

These failures are caused because subprocess.check_output's return type is wrongly Any. The other failures are like this too. Should we put # type: ignore to all of the failures?

[JukkaL]

We are planning to improve the signature of subprocess.check_output soon. Maybe we should wait for this.

[awoimbee]

The ff: Any; ff() thing just made me lost hours because a type-hint was lost in a call like a.b.c.d(). Pylance resolved the type correctly but mypy silently failed and did not prevent Missing positional argument [...]