Skip to content
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

Jump to bottom

[red-knot] remove TODO catch-all case in infer_unary_expression #14548

Open
carljm opened this issue Nov 22, 2024 · 2 comments
Open

[red-knot] remove TODO catch-all case in infer_unary_expression #14548

carljm opened this issue Nov 22, 2024 · 2 comments
Assignees
@carljm
Labels
red-knot Multi-file analysis & type inference

Comments

@carljm
Copy link
Contributor

carljm commented Nov 22, 2024 •
edited
Loading

Currently, the method TypeInferenceBuilder::infer_unary_expression handles some common cases, and has a catch-all arm that simply infers a "todo" type.

This issue is to remove that todo catch-all case, and replace it with correct handling of all missing cases.

For many of the unhandled types (e.g. Type::FunctionLiteral, Type::ClassLiteral, Type::SubclassOf) the correct handling will be to treat it as a Type::Instance type (an instance of types.FunctionType, or an instance of the meta-type of a class) and let the normal instance handling from typeshed take care of it.

(note: edited description for correctness, which will make some comments below look out-of-context)
@carljm carljm added the red-knot Multi-file analysis & type inference label Nov 22, 2024
@carljm carljm self-assigned this Nov 22, 2024
@carljm carljm mentioned this issue Nov 22, 2024
Open
@AlexWaygood
Copy link
Member

AlexWaygood commented Nov 23, 2024 •
edited
Loading

For many of the unhandled types (e.g. Type::FunctionLiteral, Type::ClassLiteral, Type::SubclassOf) the correct handling will simply be an unsupported-operator diagnostic.

Hmm, I don't think that's correct when it comes to Type::ClassLiteral and Type::SubclassOf. We need to treat a class as an instance of its metaclass when determining if a unary operation is supported on that class or not. (Same deal as #14200.)

@carljm
Copy link
Contributor Author

carljm commented Nov 23, 2024 •
edited
Loading

Yes, good point! I looked at functions and then thoughtlessly lumped classes in with them.

Even for functions, we should treat them as an instance of types.FunctionType and defer to typeshed, rather than hardcoding the unsupported-operator diagnostic.

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

@carljm carljm

Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@carljm @AlexWaygood