-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[red-knot] Infer lambda expression
#16547
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
Conversation
3d132d6 to
e4da8a3
Compare
e4da8a3 to
7d8fdb0
Compare
AlexWaygood
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great, thanks!
| let file = input.file(db); | ||
| let _span = tracing::trace_span!( | ||
| "infer_definition_types_cycle_recovery", | ||
| range = ?input.kind(db).target_range(), | ||
| file = %file.path(db) | ||
| ) | ||
| .entered(); | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is similar to infer_definition_types and it allowed me to quickly understand the origin of the cycle and what was causing it.
|
carljm
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thank you!
|
As we discussed in 1:1, we can infer a return type in some cases if we make default values of the parameters standalone expressions, so they can be resolved without creating a cycle. Longer term, we may want to do "inlining" of lambdas at their usage sites so we can do better transparent inference, but that's for later. |
* main: [red-knot] Rework `Type::to_instance()` to return `Option<Type>` (#16428) [red-knot] Add tests asserting that `KnownClass::to_instance()` doesn't unexpectedly fallback to `Type::Unknown` with full typeshed stubs (#16608) [red-knot] Handle gradual intersection types in assignability (#16611) [red-knot] mypy_primer: split installation and execution (#16622) [red-knot] mypy_primer: pipeline improvements (#16620) [red-knot] Infer `lambda` expression (#16547) [red-knot] mypy_primer: strip ANSI codes (#16604) [red-knot] mypy_primer: comment on PRs (#16599)
Summary
Part of #15382
This PR adds support for inferring the
lambdaexpression and return theCallableType.Currently, this is only limited to inferring the parameters and a todo type for the return type.
For posterity, I tried using the
file_expression_typeto infer the return type of lambda but it would always lead to cycle. The main reason is that ininfer_parameter_definition, the default expression is being inferred usingfile_expression_type, which is correct, but it thenTake the following source code as an example:
Here's how the code will flow:
infer_scope_typesfor the global scopeinfer_lambda_expressioninfer_expressionfor the default value1file_expression_typefor the return type using the body expression. This is because the body creates it's own scopeinfer_scope_types(lambda body scope)infer_name_loadfor the symbolxwhose visible binding is the lambda parameterxinfer_parameter_definitionfor parameterxfile_expression_typefor the default value1infer_scope_typesfor the global scope because of the default expressionThis will then reach to
infer_definitionfor the parameterxagain which then creates the cycle.Test Plan
Add tests around
lambdaexpression inference.