Add unbound typevar check

[AurelienJaquier]

Description

This should fix Issue #13061 .

Mypy should now raise an error when it encounters unbound plain TypeVar.
It should not get triggered when the return type contains a TypeVar (e.g. List[T]).
It should not get triggered when a same TypeVar is present in the scope (e.g. inner function returns T, and T is an argument of outer function).

Test Plan

5 tests were added:

• a plain unbound typevar triggering the new error
• a typevar inner function not triggering the error
• a function returning an iterable of typevars, not triggering the error
• a plain bound typevar, not triggering the error
• nested bound typevars, not triggering the error

We also changed the other functions triggering our error for the tests to pass.

This is our 1st contribution to Mypy. Please, guide us if there is anything we can improve in this PR.

This PR was made with @anilbey

[ilevkivskyi]

Thanks, looks good! (assuming the tests pass)

[anilbey]

Good news! 🎉

[hauntsaninja]

Could you add a test for upper bounded and constrained type vars?

I would also avoid opening PRs to projects that add type: ignore, since they likely won't be able to merge the PR until there's a new version of mypy. Besides, fixes are much preferred to adding type-ignores. If we just want to type-ignore most instances of this error, it'd be a sign that we shouldn't add it ;-)

[hauntsaninja]

Could we micro optimise this by first checking if typ.ret_type in typ.variables and only then doing the collection of arg types?

[anilbey]

Good idea!

[anilbey]

addressed in the latest push

[hauntsaninja]

could you add one more test case with something more nested, say List[Union[Callable[..., Tuple[T]]]]

[anilbey]

Done with the last push.

[hauntsaninja]

If the typevar is upper bounded or constrained, we could actually suggest using the upper bound or the union of the constraints as the return type. This seems very common, e.g. see the pandas, spark, etc cases.

[ilevkivskyi]

Btw, this reminds me some people use returning a plain unbound type var with values as a way to emulate unsafe unions. But as many of you know I don't like unsafe unions, so I am fine with breaking such hacks.

[ilevkivskyi]

@anilbey @AurelienJaquier it would be great if you could implement some of the suggestions, but if you don't have time or want to do it in a separate PR it is also OK, please let me know.

[anilbey]

Thanks @hauntsaninja for the feedback.
@ilevkivskyi I just added the deeper nested tests and micro optimisation. For upper bounded and constrained types, I will need a bit of more time.

[ilevkivskyi]

OK, you can make those other changes in a separate PR. I will merge this when the tests pass.

[ilevkivskyi]

@anilbey Unfortunately one of the tests you added is failing, probably you need to add a builtins fixture that includes tuple (you can see how it is done in other tests).

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

pegen (https://github.com/we-like-parsers/pegen)
+ src/pegen/parser.py:25: error: A function returning TypeVar should receive at least one argument containing the same Typevar  [type-var]
+ src/pegen/parser.py:45: error: A function returning TypeVar should receive at least one argument containing the same Typevar  [type-var]

pandera (https://github.com/pandera-dev/pandera)
+ pandera/engines/engine.py:184: error: A function returning TypeVar should receive at least one argument containing the same Typevar  [type-var]

paasta (https://github.com/yelp/paasta)
+ paasta_tools/utils.py:3941: error: A function returning TypeVar should receive at least one argument containing the same Typevar
+ paasta_tools/utils.py:3948: error: A function returning TypeVar should receive at least one argument containing the same Typevar

anyio (https://github.com/agronholm/anyio)
+ src/anyio/from_thread.py:122: error: A function returning TypeVar should receive at least one argument containing the same Typevar  [type-var]

vision (https://github.com/pytorch/vision)
+ torchvision/prototype/datasets/utils/_internal.py:89: error: A function returning TypeVar should receive at least one argument containing the same Typevar  [type-var]

spark (https://github.com/apache/spark)
+ python/pyspark/ml/wrapper.py:267: error: A function returning TypeVar should receive at least one argument containing the same Typevar  [type-var]

tornado (https://github.com/tornadoweb/tornado)
+ tornado/queues.py:384: error: A function returning TypeVar should receive at least one argument containing the same Typevar
+ tornado/queues.py:421: error: A function returning TypeVar should receive at least one argument containing the same Typevar

schemathesis (https://github.com/schemathesis/schemathesis)
+ src/schemathesis/auth.py: note: In member "get" of class "AuthProvider":
+ src/schemathesis/auth.py:36: error: A function returning TypeVar should receive at least one argument containing the same Typevar

steam.py (https://github.com/Gobot1234/steam.py)
+ steam/ext/commands/commands.py:1046: error: A function returning TypeVar should receive at least one argument containing the same Typevar  [type-var]
+ steam/ext/commands/commands.py:1077: error: A function returning TypeVar should receive at least one argument containing the same Typevar  [type-var]

core (https://github.com/home-assistant/core)
+ homeassistant/helpers/singleton.py:29: error: A function returning TypeVar should receive at least one argument containing the same Typevar  [type-var]

Tanjun (https://github.com/FasterSpeeding/Tanjun)
+ tanjun/dependencies/data.py:321: error: A function returning TypeVar should receive at least one argument containing the same Typevar  [type-var]

[anilbey]

OK, you can make those other changes in a separate PR. I will merge this when the tests pass.

Alright, sounds good