Improved error context for diagnostics involving assignment checks

[sharkdp]

Now that the initial version of error context collection has been merged, let's collect a few scenarios in which we could improve the diagnostics by adding more (detailed) context:

No short-circuiting

We currently short-circuit on assignability checks. For example, when checking if A | B is assignable to Target, and the assignment A -> Target fails, we already know that the overall assignment will fail. However, this is not ideal for error context collection since we don't get to see if B would have been assignable or not. We should probably play with disabling short-circuiting behavior in the second pass of an assignability check (when we actually collect the error context). This would improve diagnostics like:

• https://github.com/astral-sh/ruff/blob/47d5cc47bca41a810a035fcb748b51ae0af8ec24/crates/ty_python_semantic/resources/mdtest/diagnostics/invalid_argument_type.md?plain=1#L566-L572
• https://github.com/astral-sh/ruff/blob/47d5cc47bca41a810a035fcb748b51ae0af8ec24/crates/ty_python_semantic/resources/mdtest/snapshots/function.md_-_Call_expression_-_Wrong_argument_type_-_Diagnostics_for_unio%E2%80%A6_(5396a8f9e7f88f71).snap#L76-L109

Assigning to Iterable (and other commonly used protocols?)

For a list[str] → Iterable[bytes] assignment, we currently emit

error[invalid-assignment]: Object of type `list[str]` is not assignable to `Iterable[bytes]`
 --> src/mdtest_snippet.py:4:13
  |
4 |     target: Iterable[bytes] = source  # snapshot
  |             ---------------   ^^^^^^ Incompatible value of type `list[str]`
  |             |
  |             Declared type
  |
info: type `list[str]` is not assignable to protocol `Iterable[bytes]`
info: └── protocol member `__iter__` is incompatible
info:     └── incompatible return types: `Iterator[str]` is not assignable to `Iterator[bytes]`
info:         └── protocol `Iterator[str]` is not assignable to protocol `Iterator[bytes]`
info:             └── incompatible return types: `str` is not assignable to `bytes`

This is not technically wrong but could certainly be improved with a dedicated hint that summarizes this as something like

info: type `list[str]` is not assignable to protocol `Iterable[bytes]`
info: └── expected an iterator over `bytes`, but got `str`

Better support for callables

• When the number of parameters is incorrect, we should highlight this as the problem. See test here.
• When assigning to and from an overload set, we should highlight problematic overloads. See test here.
• When assigning a class to a Callable type, we should potentially add the signature of the constructor to the error context (see this test).

Support for TypedDicts

At the very least, we should call out incompatible and missing field. See existing tests here.

Incompatible specializations

When assigning a fully specialized instance of a generic class to another fully specialized instance of that same generic class, we should explain why they are not compatible (including information about the variance of the corresponding type variables). For example, here we should explain that the assignment fails because the second type parameter is contravariant, but bool is not assignable to int:

class MyClass[Covariant, Contravariant, Invariant]:
    i: Invariant

    def get(self) -> Covariant:
        raise

    def set(self, value: Contravariant) -> None: ...


def _(source: MyClass[str, bool, bytes]):
    target: MyClass[object, int, bytes] = source

Intersection support

This should hopefully be similar to support for unions, just ... dual. See existing tests here.

Type aliases

When type alias are involved, we could add an additional error context node that shows how how we unwrap the type alias (OptionalNumber -> float | None). See test here.

[AlexWaygood]

Another improvement I'd love to see (which might be nontrivial to implement -- not sure?) would be to integrate the error context into the annotations we use in our diagnostics.

---

For example, on this snippet:

class Parent:
    def foo(self, x): ...

class Child(Parent):
    def foo(self, y): ...

we currently render this diagnostic:

error[invalid-method-override]: Invalid override of method `foo`
 --> foo.py:2:9
  |
2 |     def foo(self, x): ...
  |         ------------ `Parent.foo` defined here
3 |
4 | class Child(Parent):
5 |     def foo(self, y): ...
  |         ^^^^^^^^^^^^ Definition is incompatible with `Parent.foo`
  |
info: the parameter named `y` does not match `x` (and can be used as a keyword parameter)
info: This violates the Liskov Substitution Principle

Which is a significant improvement on what we had previously -- but even better would be:

error[invalid-method-override]: Invalid override of method `foo`
 --> foo.py:2:9
  |
2 |     def foo(self, x): ...
  |         ^^^       - First parameter is named `x`
  |         |
  |         `Parent.foo` defined here
3 |
4 | class Child(Parent):
5 |     def foo(self, y): ...
  |         ^^^       - First parameter is incompatibly named `y`
  |         |
  |         Definition is incompatible with `Parent.foo`
  |
info: `Parent.foo` can be passed an `x` keyword argument but `Child.foo` cannot
info: This violates the Liskov Substitution Principle

---

We could do something similar for our protocol diagnostics. On this snippet:

from typing import Protocol

class Proto(Protocol):
    def foo(self, x): ...

class Concrete:
    def foo(self, y): ...

thing: Proto = Concrete()

we currently emit this diagnostic:

error[invalid-assignment]: Object of type `Concrete` is not assignable to `Proto`
 --> foo.py:9:8
  |
9 | thing: Proto = Concrete()
  |        -----   ^^^^^^^^^^ Incompatible value of type `Concrete`
  |        |
  |        Declared type
  |
info: type `Concrete` is not assignable to protocol `Proto`
info: └── protocol member `foo` is incompatible
info:     └── the parameter named `y` does not match `x` (and can be used as a keyword parameter)

which could plausibly be

error[invalid-assignment]: Object of type `Concrete` is not assignable to `Proto`
 --> foo.py:9:8
  |
9 | thing: Proto = Concrete()
  |        -----   ^^^^^^^^^^ Incompatible value of type `Concrete`
  |        |
  |        Declared type
  |
info: type `Concrete` is not assignable to protocol `Proto`
info: └── protocol member `foo` is incompatible
  |
4 |     def foo(self, x): ...
  |         ^^^       - `Proto.foo` has an `x` parameter
  |         |
  |         Definition of `Proto.foo`
  |
5 |
6 | class Concrete:
7 |     def foo(self, y): ...
  |         ^^^       - `Concrete.foo` has a `y` parameter
  |         |
  |         Definition of `Concrete.foo`
  |
info: `Proto.foo` can be passed an `x` keyword argument but `Concrete.foo` cannot