Ensure that CheckValue isn't called twice on lambda query receivers #80010
Conversation
When creating query expressions, most of the time the receiver the query is not checked for being a valid RValue by calling code. However, in one case, it is; this can then cause an assert that we are checking for field-backed property access multiple times. Fixes dotnet#80008.
|
|
||
| // We transform the expression from "expr" to "expr.Cast<castTypeOpt>()". | ||
| boundExpression = lambdaBodyBinder.MakeQueryInvocation(expression, boundExpression, "Cast", castTypeSyntax, castType, diagnostics | ||
| boundExpression = lambdaBodyBinder.MakeQueryInvocation(expression, boundExpression, receiverIsCheckedForRValue: true, "Cast", castTypeSyntax, castType, diagnostics |
There was a problem hiding this comment.
This is the bug: lambdaBodyBinder.BindValue above calls CheckValue on its result. In every other MakeQueryInvocation callsite, we are not passing something that has already been checked; this is the only location where we are.
There was a problem hiding this comment.
Just to confirm, the added tests in this file also asserted before this change.
|
@dotnet/roslyn-compiler for review. |
333fred
force-pushed
the
fix-property-access
branch
from
7406282 to
7a95ae3
Compare
| receiver = new BoundBadExpression(receiver.Syntax, LookupResultKind.NotAValue, ImmutableArray<Symbol?>.Empty, ImmutableArray.Create(receiver), CreateErrorType()); | ||
| } | ||
| else | ||
| else if (!receiverIsCheckedForRValue) |
There was a problem hiding this comment.
Is there any risk that we will not call updateUltimateReceiver for this expression now and have the wrong receiver in the bound tree?
There was a problem hiding this comment.
No. The body here is not a BoundQueryClause.
333fred
force-pushed
the
fix-property-access
branch
from
7a95ae3 to
65e88a8
Compare
|
@dotnet/roslyn-compiler for a second review |
1 similar comment
|
@dotnet/roslyn-compiler for a second review |
4 participants
When creating query expressions, most of the time the receiver the query is not checked for being a valid RValue by calling code. However, in one case, it is; this can then cause an assert that we are checking for field-backed property access multiple times. Fixes #80008.