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.

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

[red-knot] infer types from parameter annotations #13693

Closed
carljm opened this issue Oct 9, 2024 · 0 comments · Fixed by #14802
Closed

[red-knot] infer types from parameter annotations #13693

carljm opened this issue Oct 9, 2024 · 0 comments · Fixed by #14802
Assignees
Labels
red-knot Multi-file analysis & type inference
Milestone

Comments

@carljm
Copy link
Contributor

carljm commented Oct 9, 2024

Currently we have Definitions for function parameters (that is, inside the function body we know that those names are defined), but we only infer @Todo types for those names, even if the parameter has a type annotation.

The tricky part of implementing this inference correctly is that we have to handle PEP 695 generic type parameter scopes, e.g. def f[T](x: T): ... has a special implicit scope in between the containing scope and the function's body scope, in which T is defined. So for generic functions we have to do inference of the parameter type annotations in that scope, not in the outer scope.

@carljm carljm added the red-knot Multi-file analysis & type inference label Oct 9, 2024
@carljm carljm added this to the Red Knot 2024 milestone Nov 7, 2024
carljm added a commit that referenced this issue Nov 13, 2024
When we look up the types of class bases or keywords (`metaclass`), we
currently do this little dance: if there are type params, then look up
the type using `SemanticModel` in the type-params scope, if not, look up
the type directly in the definition's own scope, with support for
deferred types.

With inference of function parameter types, I'm now adding another case
of this same dance, so I'm motivated to make it a bit more ergonomic.

Add support to `definition_expression_ty` to handle any sub-expression
of a definition, whether it is in the definition's own scope or in a
type-params sub-scope.

Related to both #13693 and #14161.
@carljm carljm assigned carljm and unassigned AlexWaygood Nov 14, 2024
carljm added a commit that referenced this issue Nov 14, 2024
## Summary

Add a typed representation of function signatures (parameters and return
type) and infer it correctly from a function.

Convert existing usage of function return types to use the signature
representation.

This does not yet add inferred types for parameters within function body
scopes based on the annotations, but it should be easy to add as a next
step.

Part of #14161 and #13693.

## Test Plan

Added tests.
carljm added a commit that referenced this issue Dec 6, 2024
## Summary

Inferred and declared types for function parameters, in the function
body scope.

Fixes #13693.

## Test Plan

Added mdtests.

---------

Co-authored-by: Micha Reiser <micha@reiser.io>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants