[ty] Fall back to Divergent for deeply nested specializations

[sharkdp]

Summary

Fall back to C[Divergent] if we are trying to specialize C[T] with a type that itself already contains deeply nested specialized generic classes. This is a way to prevent infinite recursion for cases like self.x = [self.x] where type inference for the implicit instance attribute would not converge.

closes astral-sh/ty#1383
closes astral-sh/ty#837

Test Plan

Regression tests.

[sharkdp]

I haven't understood the scope parameter of Type::Divergent. When we see an infinitely wrapped list[list[list[…]]] in a method of class C, is it still correct to set the scope parameter to the body scope of list (not of C or the method) here?

[mtshiba]

Your use of Divergent in this PR seems to differ slightly from the original intended use. The intended use is to make functions with the potential for divergent type inference tracked, and to set the initial cycle value to Divergent instead of Never. If the resulting type contains Divergent, replace that type with Divergent itself to converge the inference.

https://github.com/astral-sh/ruff/pull/17371/files#diff-20b910c6e20faa962bb1642e111db1cbad8e66ace089bdd966ac9d7f9fa99ff2R649-R665

When I first introduced Divergent in #20312, I included scope to prevent Divergent from propagating to other types of inference. This was based on the use case in #17371.

e3b896d#diff-fdebb876f3c3f16730728018e4b1223f844d9493cd7caa7ee94e4a7a7b02184f

call_divergent calls divergent, but it does not diverge itself. Knowing where the divergence occurs can help prevent excessive type replacement.

#20333 and #20359 may also be helpful in understanding Divergent.

[sharkdp]

I currently don't see how that approach scales. We would need to add dedicated "turn this type into Divergent if it contains Divergent" logic everywhere. We can do this for tuples, but we also need to do it for sets, lists, and dicts. And it doesn't really stop with those syntactical constructs. What about something like

from typing import TypeVar, Literal

T = TypeVar("T")

def make_tuple(a: T) -> tuple[T, Literal[1]]:
    return (a, 1)

class D:
    def f(self, other: "D"):
        self.x = make_tuple(other.x)

reveal_type(D().x)

Do we also specialize all call expressions to detect nested Divergent types? At that point, we could probably add it to infer_expression_type (and in fact, that might work, but done naively, we would get Divergent instead of tuple[Divergent, …] etc).

What I'm proposing here is certainly not very elegant, I agree. But it does solve all of these cases (and more) without any special casing to certain syntactical forms.

[mtshiba]

I don't actually think it's necessary to apply this logic everywhere. That's work in progress in #20566.

The only place where this logic needs to be applied is within tracked functions that may diverge (e.g. implicit_attribute_inner, infer_expression_type_impl). That means that a Divergent-type suppression needs to be performed by the end of a cycle, and it would be most natural to do this at the end of the tracked function. Other places, such as infer_tuple_expression, don't actually need this logic. In fact, it's been removed in https://github.com/astral-sh/ruff/pull/20566/files#diff-5ade3020ce233d81ee50c1ec2debd673afc8ba08ede8ec664ca62e62aefbb2f7L5273-L5279, https://github.com/astral-sh/ruff/pull/20566/files#diff-411da1a5c9e0560d6b43091ca27247357a1e94a9077f9adb2cd6a23f495578b6L24-L28.

cc (as author of #20333, etc.): @carljm

[sharkdp]

I had completely missed #20566 — thank you for the reference. It looks like that still requires adding divergent-handling in lots of places, but I'm certainly not opposed to that. I would very much like there to be a more principled solution.

My problem is that I want something that fixes these panics now (to finally merge the type-of-self PR). I rolled back most of the changes here to leave the CycleRecovery setup intact and to be less invasive. I am proposing that we merge this PR to solve the immediate problem, and I'll be happy to remove all of this once we have a better solution (that still solves all of the test cases that are introduced in this PR).

[mtshiba]

Yes, as I said here, I'm in favor of provisionally merging the PR anyway; the lack of self types means that a lot of recursive type inference is hidden by dynamic types.

[sharkdp]

Thank you for chiming in here, very much appreciated!

[github-actions]

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

[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]

Thank you