[ty] Handle covariant "deep" mutual typevar constraints
This is the first step in supporting https://github.com/astral-sh/ty/issues/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]]
Diagnostic diff on typing conformance tests
No changes detected when running ty on typing conformance tests ✅
CodSpeed Performance Report
Merging #22043 will not alter performance
Comparing dcreager/generic-horn-clauses (e1f9ba7) with main (cdb7a9f)
Summary
✅ 22 untouched
⏩ 30 skipped[^skipped]
[^skipped]: 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.
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)
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?