[ty] Handle annotated self parameter in constructor of non-invariant generic classes

[dcreager]

This manifested as an error when inferring the type of a PEP-695 generic class via its constructor parameters:

class D[T, U]:
    @overload
    def __init__(self: "D[str, U]", u: U) -> None: ...
    @overload
    def __init__(self, t: T, u: U) -> None: ...
    def __init__(self, *args) -> None: ...

# revealed: D[Unknown, str]
# SHOULD BE: D[str, str]
reveal_type(D("string"))

This manifested because D is inferred to be bivariant in both T and U. We weren't seeing this in the equivalent example for legacy typevars, since those default to invariant. (This issue also showed up for covariant typevars, so this issue was not limited to bivariance.)

The underlying cause was because of a heuristic that we have in our current constraint solver, which attempts to handle situations like this:

def f[T](t: T | None): ...
f(None)

Here, the None argument matches the non-typevar union element, so this argument should not add any constraints on what T can specialize to. Our previous heuristic would check for this by seeing if the argument type is a subtype of the parameter annotation as a whole — even if it isn't a union! That would cause us to erroneously ignore the self parameter in our constructor call, since bivariant classes are equivalent to each other, regardless of their specializations.

The quick fix is to move this heuristic "down a level", so that we only apply it when the parameter annotation is a union. This heuristic should go away completely 🤞 with the new constraint solver.

[github-actions]

Diagnostic diff on typing conformance tests

Changes were detected when running ty on typing conformance tests

--- old-output.txt	2025-11-11 00:35:18.990083765 +0000
+++ new-output.txt	2025-11-11 00:35:22.335106572 +0000
@@ -937,7 +937,6 @@
 tuples_type_compat.py:127:13: error[type-assertion-failure] Argument does not have asserted type `@Todo(Support for `typing.TypeAlias`)`
 tuples_type_compat.py:129:13: error[type-assertion-failure] Argument does not have asserted type `tuple[int | str, int]`
 tuples_type_compat.py:130:13: error[type-assertion-failure] Argument does not have asserted type `@Todo(Support for `typing.TypeAlias`)`
-tuples_type_compat.py:153:5: error[type-assertion-failure] Argument does not have asserted type `Sequence[Never]`
 tuples_type_compat.py:157:1: error[invalid-assignment] Object of type `tuple[Literal[1], Literal[""], Literal[""]]` is not assignable to `tuple[int, str]`
 tuples_type_compat.py:162:1: error[invalid-assignment] Object of type `tuple[Literal[1], Literal[1], Literal[""]]` is not assignable to `tuple[int, *tuple[str, ...]]`
 tuples_type_compat.py:163:1: error[invalid-assignment] Object of type `tuple[Literal[1], Literal[""], Literal[1]]` is not assignable to `tuple[int, *tuple[str, ...]]`
@@ -1007,5 +1006,5 @@
 typeddicts_usage.py:28:17: error[missing-typed-dict-key] Missing required key 'name' in TypedDict `Movie` constructor
 typeddicts_usage.py:28:18: error[invalid-key] Invalid key for TypedDict `Movie`: Unknown key "title"
 typeddicts_usage.py:40:24: error[invalid-type-form] The special form `typing.TypedDict` is not allowed in type expressions. Did you mean to use a concrete TypedDict or `collections.abc.Mapping[str, object]` instead?
-Found 1009 diagnostics
+Found 1008 diagnostics
 WARN A fatal error occurred while checking some files. Not all project files were analyzed. See the diagnostics list above for details.

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

No memory usage changes detected ✅

[github-actions]

ecosystem-analyzer results

No diagnostic changes detected ✅
Full report with detailed diff (timing results)

[AlexWaygood]

LGTM