[ty] Don't include already-bound legacy typevars in function generic context

[dcreager]

We now correctly exclude legacy typevars from enclosing scopes when constructing the generic context for a generic function.

more detail:

A function is generic if it refers to legacy typevars in its signature:

from typing import TypeVar

T = TypeVar("T")

def f(t: T) -> T:
    return t

Generic functions are allowed to appear inside of other generic contexts. When they do, they can refer to the typevars of those enclosing generic contexts, and that should not rebind the typevar:

from typing import TypeVar, Generic

T = TypeVar("T")
U = TypeVar("U")

class C(Generic[T]):
    @staticmethod
    def method(t: T, u: U) -> None: ...

# revealed: def method(t: int, u: U) -> None
reveal_type(C[int].method)

This substitution was already being performed correctly, but we were also still including the enclosing legacy typevars in the method's own generic context, which can be seen via ty_extensions.generic_context (which has been updated to work on generic functions and methods):

from ty_extensions import generic_context

# before: tuple[T, U]
# after: tuple[U]
reveal_type(generic_context(C[int].method))

[github-actions]

mypy_primer results

Changes were detected when running on open source projects

psycopg (https://github.com/psycopg/psycopg)
- psycopg/psycopg/_py_transformer.py:329:16: error[invalid-return-type] Return type does not match returned value: expected `Row`, found `tuple[Any, ...]`
- psycopg_pool/psycopg_pool/pool.py:263:16: error[invalid-return-type] Return type does not match returned value: expected `CT`, found `(Unknown & ~AlwaysFalsy) | Connection[@Todo(Support for `typing.TypeAlias`)]`
- Found 658 diagnostics
+ Found 656 diagnostics

zulip (https://github.com/zulip/zulip)
- zerver/tests/test_auth_backends.py:8035:26: error[invalid-argument-type] Argument to bound method `set` is incorrect: Argument type `Unknown | int` does not satisfy upper bound of type variable `Self`
- Found 7421 diagnostics
+ Found 7420 diagnostics

No memory usage changes detected ✅

[carljm]

Looks good!

[carljm]

Related to above, I'd suggest instead of taking module or index we might just take a File here.

Or take only a ScopeId, which encompasses a File and a FileScopeId.

I guess the one argument in favor of taking module and index is that it kind of makes it explicit that this method has a dependency on the AST of the module containing scope. But I'm not sure how obvious this is; it's not the way we've typically handled this.

[dcreager]

Done.

I guess the one argument in favor of taking module and index is that it kind of makes it explicit that this method has a dependency on the AST of the module containing scope.

That wasn't my intent, and I think it's an open question how we want to model that better more generally, so I'm going with the simpler function signatures that you've suggested

[carljm]

infer.rs is already massive with TypeInferenceBuilder and the various *Inference structs. Is it the best place for these new free functions? Seems like they kind of would belong in generics.rs.

[dcreager]

Moved. That also let me make them file-local instead of pub(crate)