Skip to content

Conversation

@sterliakov
Copy link
Collaborator

Fixes #20135.

I am not fully certain that this is the right way. If the type alias can be reasonably constructed and only type parameters prevent that, we can create an "almost" equivalent alias with all placeholder-bearing typevars replaced with their "simple" equivalents with default values/bound/default values. This would cause current iteration to not emit some parameterization errors later, but, since we already defer the alias as a whole, we will recheck all of them again.

This obviously adds some pointless work (we check parameterization that will not be used later), but probably is not that big of a deal, recursive aliases are relatively rare in wild. If this turns out to be a bottleneck, we can add a parameters_ready flag to aliases and skip the heavy parts if it is False, but I think it isn't necessary now.

is_error = False
is_invalid = False
for (i, arg), tvar in zip(enumerate(args), type_vars):
for arg, tvar in zip(args, type_vars):
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This change does not belong here, but I don't think it warrants a separate PR - i was just unused, I noticed it when tracing a PlaceholderType

@github-actions

This comment has been minimized.

@sterliakov sterliakov marked this pull request as ready for review November 1, 2025 21:18
@github-actions
Copy link
Contributor

github-actions bot commented Nov 4, 2025

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Crash on jsonesque recursive type alias (regression 1.17.1 ⟹ 1.18.1)

1 participant