Skip to content

gh-20542: Fix crash in split_for_callable when passing values to variadic generics #20543

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
hauntsaninja merged 3 commits into from
Jan 13, 2026
Merged

gh-20542: Fix crash in split_for_callable when passing values to variadic generics #20543

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d69a129
fix crash in split_for_callable when passing values to variadic generics
a12k Jan 7, 2026
f37f381
Refactor test to work with python 3.10/3.11, and 3.12+
a12k Jan 7, 2026
4b94d5d
Refactoring to simplify
a12k Jan 8, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion mypy/checkexpr.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4966,7 +4966,9 @@ class C(Generic[T, Unpack[Ts]]): ...
if not vars or not any(isinstance(v, TypeVarTupleType) for v in vars):
Copy link
Collaborator

@A5rocks A5rocks Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if you add or not t.is_type_obj()? Does mypy error later? The error message you added isn't very clear IMO.

Copy link
Contributor Author

@a12k a12k Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking if we added or not t.is_type_obj() to the guard it would return more generic errors. In the test below, the return is Invalid type: try using Literal[1] instead? but with the additional guard I think it would be something like error: Type expected?, which is correct, but not as specific as it could be.

I probably should use the messagebuilder for the error though. :)

Copy link
Collaborator

@A5rocks A5rocks Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which one is the current? Neither matches what you have ATM?

Copy link
Contributor Author

@a12k a12k Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah! I'm sorry, I misread what line you were commenting on. You're saying why not turn if not vars or not any(isinstance(v, TypeVarTupleType) for v in vars): to if not vars or not any(isinstance(v, TypeVarTupleType) for v in vars) or not t.is_type_object().

I tried this and we produce the Type application is only supported for generic classes and Invalid type: try using Literal[1] instead? in the test against this part of the code. Looking at it, I'm thinking this is likely a lot cleaner and I would just suggest striking my current changes and changing to simply appending or not t.is_type_object() to line 4966. What do you think?

Copy link
Collaborator

@A5rocks A5rocks Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that seems like a better error output, if I'm understanding correctly.

return list(args)
# TODO: in future we may want to support type application to variadic functions.
assert t.is_type_obj()
if not t.is_type_obj():
self.chk.fail(f"Invalid type argument: type expected, for {args[0]!r}", ctx)
return [AnyType(TypeOfAny.from_error)] * len(vars)
info = t.type_object()
# We reuse the logic from semanal phase to reduce code duplication.
fake = Instance(info, args, line=ctx.line, column=ctx.column)
Expand Down
20 changes: 20 additions & 0 deletions test-data/unit/check-typevar-tuple.test
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2754,3 +2754,23 @@ class X(Generic[Unpack[Ts]]):
def c(t: X[Concatenate[int, ...]]) -> None: # E: Cannot use "[int, VarArg(Any), KwArg(Any)]" for TypeVarTuple, only for ParamSpec
reveal_type(t) # N: Revealed type is "__main__.X[Unpack[builtins.tuple[Any, ...]]]"
[builtins fixtures/tuple.pyi]

[case testTypeVarTupleLiteralValueAsTypeArgument]
from typing import TypeVarTuple, Generic, Unpack, Callable, TypeVar

Ts = TypeVarTuple('Ts')
T = TypeVar('T')

class C(Generic[Unpack[Ts]]):
pass

x = C[1, 2, 3]() # E: Invalid type: try using Literal[1] instead? \
# E: Invalid type: try using Literal[2] instead? \
# E: Invalid type: try using Literal[3] instead?

def func(d: Callable[[Unpack[Ts]], T]) -> T: ...

y = func[1, int] # E: Type application is only supported for generic classes \
# E: Invalid type argument: type expected, for Any \
# E: Invalid type: try using Literal[1] instead?
[builtins fixtures/tuple.pyi]