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
fix(compiler-cli): incorrectly type checking calls to implicit template variables #39686
Conversation
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.
Nice work @crisbeto - it is great when things can be fixed so simply. Thanks for picking up this issue and resolving it so quickly.
packages/compiler-cli/src/ngtsc/typecheck/src/type_check_block.ts
Outdated
Show resolved
Hide resolved
packages/compiler-cli/src/ngtsc/typecheck/src/type_check_block.ts
Outdated
Show resolved
Hide resolved
46e6cec
to
3a29804
Compare
…te variables Currently when we encounter an implicit method call (e.g. `{{ foo(1) }}`) and we manage to resolve its receiver to something within the template, we assume that the method is on the receiver itself so we generate a type checking code to reflect it. This assumption is true in most cases, but it breaks down if the call is on an implicit receiver and the receiver itself is being invoked. E.g. ``` <div *ngFor="let fn of functions">{{ fn(1) }}</div> ``` These changes resolve the issue by generating a regular function call if the method call's receiver is pointing to `$implicit`. Fixes angular#39634.
3a29804
to
9b20277
Compare
…te variables (#39686) Currently when we encounter an implicit method call (e.g. `{{ foo(1) }}`) and we manage to resolve its receiver to something within the template, we assume that the method is on the receiver itself so we generate a type checking code to reflect it. This assumption is true in most cases, but it breaks down if the call is on an implicit receiver and the receiver itself is being invoked. E.g. ``` <div *ngFor="let fn of functions">{{ fn(1) }}</div> ``` These changes resolve the issue by generating a regular function call if the method call's receiver is pointing to `$implicit`. Fixes #39634. PR Close #39686
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Currently when we encounter an implicit method call (e.g.
{{ foo(1) }}
) and we manage to resolve its receiver to something within the template, we assume that the method is on the receiver itself so we generate a type checking code to reflect it. This assumption is true in most cases, but it breaks down if the call is on an implicit receiver and the receiver itself is being invoked. E.g.These changes resolve the issue by generating a regular function call if the method call's receiver is pointing to
$implicit
.Fixes #39634.