[ty] Handle covariant "deep" mutual typevar constraints

[dcreager]

This is the first step in supporting astral-sh/ty#2045. This handles just the covariant (i.e. easy) case. With a quick list / Sequence switcheroo, we get:

def invoke[A, B](fn: Callable[[A], B], value: A) -> B:
    return fn(value)

def head[T](xs: Sequence[T]) -> T: ...
def lift[T](x: T) -> Sequence[T]: ...

reveal_type(invoke(head, [1, 2, 3]))  # revealed: int | Unknown
reveal_type(invoke(lift, 1))  # revealed: Sequence[Literal[1]]

[astral-sh-bot]

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

[codspeed-hq]

CodSpeed Performance Report

Merging #22043 will not alter performance

_{Comparing dcreager/generic-horn-clauses (e1f9ba7) with main (cdb7a9f)}

Summary

✅ 22 untouched
⏩ 30 skipped¹

Footnotes

1. 30 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[dcreager]

Lovely. The latest mypy_primer timeout happens on homeassistant/core. I can reproduce locally. In the debug profile, it times out on every run (exit code 124 comes from the timeout command):

$ ./time.sh
15:58:13 124
15:58:58 124
15:59:43 124
16:00:28 124
16:01:13 124
16:01:58 124
16:02:43 124
16:03:28 124
16:04:13 124
16:04:58 124

Under profiling, the times out 30-50ish% of the time:

$ ./time.sh
15:50:38 1
15:51:08 124
15:51:14 1
15:51:20 1
15:51:51 124
15:51:56 1
15:52:27 124
15:52:57 124
15:53:02 1
15:53:32 124

When limited to TY_MAX_PARALLELISM=1, it doesn't time out at all.

(Also no timeouts on main, so this definitely seems to be a regression introduced by this PR)

[MichaReiser]

When limited to TY_MAX_PARALLELISM=1, it doesn't time out at all.

That's scary. It could mean that There's a fixpoint issue (where salsa fails to establish an owner thread). Or does it hang in the sense that cpu usage deops to zero and all threads are blocked?

[dcreager]

Superseded by #24079