Fix lambda contextual typing with keyword-only callables - #11609
Fix lambda contextual typing with keyword-only callables#11609Kirill (vetrovk) wants to merge 2 commits into
Conversation
|
🔒 Automated review in progress — Stella Huang (@StellaHuang95) is auto-reviewing this PR. |
| positional_callable_union: Callable[[PositionalCallable], PositionalCallable] | PositionalCallable = lambda x: x | ||
|
|
||
| # This should generate an error. | ||
| keyword_only_callback: KeywordOnlyCallback = lambda x: x |
There was a problem hiding this comment.
Warning · Non-blocking recommendation
Add a positive regression case for the enabled branch: a lambda with *args followed by a keyword-only parameter contextually typed against a keyword-only callable. The new guard's rejection behavior is well covered, but this ensures valid keyword-only lambda parameters still receive their expected type.
[verified]
| if ( | ||
| expectedParam.param.category === param.d.category && | ||
| !param.d.name === !expectedParam.param.name | ||
| !param.d.name === !expectedParam.param.name && |
There was a problem hiding this comment.
Warning · Non-blocking recommendation
This guard also prevents contextual typing for a compatible single callable such as Callable[*, value: int] assigned from lambda value: value: that lambda accepts the required value= keyword, but its parameter now falls back to Unknown. Please preserve contextual typing when the lambda parameter name matches the keyword-only expected parameter, or add coverage showing why this case must be rejected.
[verified]
|
Please mirror the keyword-only lambda-parameter compatibility guard in |
Stella Huang (StellaHuang95)
added
the
review-auto:changes-requested
| isPrivateName(param.d.name.d.value)); | ||
| const isCompatibleKeywordParam = | ||
| expectedParam.kind !== ParamKind.Keyword || | ||
| sawLambdaArgsParam || |
There was a problem hiding this comment.
Info · Optional note
isPositionOnlyParam reads paramsArePositionOnly, which is mutated later in this loop. It is correct today, but that coupling makes the matching behavior sensitive to loop ordering. Consider deriving this status up front from node.d.params, alongside positionOnlySeparatorIndex, so future refactoring cannot silently change contextual-typing behavior.
[verified]
Stella Huang (StellaHuang95)
left a comment
Stella Huang (StellaHuang95)
left a comment
There was a problem hiding this comment.
Approved via Review Center.
Stella Huang (StellaHuang95)
added
review-auto:approved
Rich Chiodo (rchiodo)
left a comment
Rich Chiodo (rchiodo)
left a comment
There was a problem hiding this comment.
Approved via Review Center.
Rich Chiodo (rchiodo)
left a comment
Rich Chiodo (rchiodo)
left a comment
There was a problem hiding this comment.
Approved via Review Center.
3 participants
Fixes #11603.
When a lambda was contextually typed from a union of callable candidates, a keyword-only parameter from one candidate could incorrectly provide the type for a positional lambda parameter. This caused the wrong candidate to influence inference instead of being rejected.
Treat a keyword-only contextual parameter as compatible only with a lambda parameter that follows
*or*args. Otherwise, skip that candidate and continue with the remaining contextual signatures.Tests cover the reported case, generic and callback-protocol variants, ordinary callable unions, positional callable objects, and the incompatible keyword-only case.
Validation:
Lambda4: 1/1 passedtypeEvaluator1.test.ts: 159/159 passednpm run build:cli:devgit diff --check