Skip to content

Fix spurious has-type error when unpacking a TypeVarTuple with a constrained TypeVar#21745

Open
omkar-334 wants to merge 1 commit into
python:masterfrom
omkar-334:fix-starexpr
Open

Fix spurious has-type error when unpacking a TypeVarTuple with a constrained TypeVar#21745
omkar-334 wants to merge 1 commit into
python:masterfrom
omkar-334:fix-starexpr

Conversation

@omkar-334

@omkar-334 omkar-334 commented Jul 18, 2026

Copy link
Copy Markdown

Fixes #21693.

Unpacking a TypeVarTuple variable like y = (*result,) gave a bogus Cannot determine type of "result" error, but only when the enclosing function also had a value-constrained TypeVar. The result silently became tuple[Any, ...].

The constrained TypeVar is what makes mypy re-check the body once per value, deep-copying the AST through TransformVisitor. Every visitor there recurses into its children and remaps Var references so they stay consistent within a copy, except visit_star_expr, which returned StarExpr(node.expr) without touching the inner expression. So in the copy the assignment target result got a fresh Var while *result still pointed at the original, which is never assigned, so its type never resolves.

The fix is a one-liner: recurse into the inner expression like everything else. I also carry over the valid flag, which the old code was dropping.

Added a regression test that fails on master and passes here. Full check, semanal, fine-grained, and transform suites pass.

@github-actions

Copy link
Copy Markdown
Contributor

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Incorrect has-type on unpacking of known TypeVarTuple type from classmethod from class with contrained generic

1 participant