Fix S3459 FP: Backing field with ref property #9383
Conversation
| @@ -184,7 +184,8 @@ private static ISet<ISymbol> GetAssignedMemberSymbols(IList<MemberUsage> memberU | |||
|
|
|||
| if (PreOrPostfixOpSyntaxKinds.Contains(parentNode.Kind()) | |||
| || (parentNode is AssignmentExpressionSyntax assignment && assignment.Left == node) | |||
| || (parentNode is ArgumentSyntax argument && (!argument.RefOrOutKeyword.IsKind(SyntaxKind.None) || TupleExpressionSyntaxWrapper.IsInstance(argument.Parent)))) | |||
| || (parentNode is ArgumentSyntax argument && (!argument.RefOrOutKeyword.IsKind(SyntaxKind.None) || TupleExpressionSyntaxWrapper.IsInstance(argument.Parent))) | |||
| || RefExpressionSyntaxWrapper.IsInstance(parentNode)) | |||
There was a problem hiding this comment.
This is too simple and introduces an FN (run with C# 9):
private int _foo; // FN
public int Foo => _foo;
void Method()
{
_ = ref _foo;
}There was a problem hiding this comment.
This is not a FN. If you get a reference to the field, you have write access to it and that write can happen anywhere. This is like calling SomeMethod(ref field) where you do not know what happens inside SomeMethod. We would need to do symbolic execution on the assigned variable to properly detect all scenarios.
There was a problem hiding this comment.
But you have access to the method where the ref was used. I accept that this is out of the scope of this ticket, but at least add a reproducer to document the limitation.
|
|
|
Peach validation |
Fixes #9106