[red-knot] fix detecting a metaclass on a not-explicitly-specialized generic base #17621
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
After #17620 (which this PR is based on), I was looking at other call sites of
Type::into_class_type, and I began to feel that all of them were currently buggy due to silently skipping unspecialized generic class literal types (though in some cases the bug hadn't shown up yet because we don't understand legacy generic classes from typeshed), and in every case they would be better off if an unspecialized generic class literal were implicitly specialized with the default specialization (which is the usual Python typing semantics for an unspecialized reference to a generic class), instead of silently skipped.So I changed the method to implicitly apply the default specialization, and added a test that previously failed for detecting metaclasses on an unspecialized generic base.
I also renamed the method to
to_class_type, because I feel we have a strong naming convention whereType::into_foois always a trivialconst fnthat simply returnsSome()if the type is of variantFooandNoneotherwise. Even the existing method (with it handling bothGenericAliasandClassLiteral, and distinguishing kinds ofClassLiteral) was stretching this convention, and the new version definitely breaks that envelope.Test Plan
Added a test that failed before this PR.