Could you please also add a test for

classC(tuple[Unpack[tuple[int, ...]]]): ...

(unless there is already such test case)? I am not sure we properly handle such types. Also maybe test not just class creation, but some tuple ops as well, such as e.g. unpacking etc.

Surprisingly we don't have such a test too, but it was already working before my patch -*tuple[int, ...] is not a trivial unpack. But your feeling is overall correct - I'm able to make it crash with

a:Atuple(a)

and also get a terrible diagnostic on

b:B_,=b# E: Variadic tuple unpacking requires a star target

despite B clearly not being variadic. I'll move this to draft for now, there's little benefit from merging a crash fix that causes a next one immediately...

This looks like a duplicate work, did you try deleting the accept just above? (if you delete it, don't forget to update the comment)

That breaks one test:

[case testValidTypeAliasValues]from typing import TypeVar, Generic, ListT = TypeVar("T", int, str)S = TypeVar("S", int, bytes)class C(Generic[T]): ...class D(C[S]): ...  # E: Invalid type argument value for "C"U = TypeVar("U")A = List[C[U]]x: A[bytes]  # E: Value of type variable "T" of "C" cannot be "bytes"V = TypeVar("V", bound=int)class E(Generic[V]): ...B = List[E[U]]y: B[str]  # E: Type argument "str" of "E" must be a subtype of "int"

Removing this line makes both errors on alias instantiation disappear. That's quite expected sinceget_proper_type calls_expand_once, so it is not equivalent to simply accepting the target alias - we do not want to ignore args here. We can limit that to only accepting if args are non-empty, but I don't think this can result in any significant speedup.

OK, this is kind of unfortunate. We already accept args in isolation at the very start (see super call), then we accept expansion, and finally the target in isolation. But I guess this is the price to pay for having both:

• Support for unrestricted type vars in alias definitions
• Doing some in-place patching in this visitor