Checking for writeable indexers in Use Range Operator feature#44951
Checking for writeable indexers in Use Range Operator feature#44951jmarolf merged 23 commits intodotnet:masterfrom
Conversation
I would add Refers to: src/Analyzers/CSharp/Tests/UseIndexOrRangeOperator/UseRangeOperatorTests.cs:323 in 5351a55. [](commit_id = 5351a55, deletion_comment = False) |
src/Analyzers/CSharp/Tests/UseIndexOrRangeOperator/UseRangeOperatorTests.cs
Show resolved
Hide resolved
src/Analyzers/CSharp/Tests/UseIndexOrRangeOperator/UseRangeOperatorTests.cs
Outdated
Show resolved
Hide resolved
src/Analyzers/CSharp/Tests/UseIndexOrRangeOperator/UseRangeOperatorTests.cs
Show resolved
Hide resolved
src/Analyzers/CSharp/Tests/UseIndexOrRangeOperator/UseRangeOperatorTests.cs
Outdated
Show resolved
Hide resolved
...alyzers/CSharp/Analyzers/UseIndexOrRangeOperator/CSharpUseRangeOperatorDiagnosticAnalyzer.cs
Show resolved
Hide resolved
CyrusNajmabadi
left a comment
There was a problem hiding this comment.
The core issue was the case of:
struct S
{
public ref S Slice(int start, int length) => throw null;
public int Length { get; }
public S this[System.Range r] { get => default; }
}here Slice returns by-ref. i.e. ref S Slice.... However, the indexer does not.
|
Thanks for the contribution! |
...alyzers/CSharp/Analyzers/UseIndexOrRangeOperator/CSharpUseRangeOperatorDiagnosticAnalyzer.cs
Outdated
Show resolved
Hide resolved
...alyzers/CSharp/Analyzers/UseIndexOrRangeOperator/CSharpUseRangeOperatorDiagnosticAnalyzer.cs
Outdated
Show resolved
Hide resolved
src/Analyzers/CSharp/Tests/UseIndexOrRangeOperator/UseRangeOperatorTests.cs
Show resolved
Hide resolved
…seRangeOperatorDiagnosticAnalyzer.cs Co-authored-by: CyrusNajmabadi <cyrus.najmabadi@gmail.com>
…seRangeOperatorDiagnosticAnalyzer.cs Co-authored-by: CyrusNajmabadi <cyrus.najmabadi@gmail.com>
|
Can we fixul the titel of this PR to be clearer? Thanks! |
...harp/Analyzers/UseIndexOrRangeOperator/CSharpUseRangeOperatorDiagnosticAnalyzer.InfoCache.cs
Outdated
Show resolved
Hide resolved
...alyzers/CSharp/Analyzers/UseIndexOrRangeOperator/CSharpUseRangeOperatorDiagnosticAnalyzer.cs
Outdated
Show resolved
Hide resolved
src/Analyzers/CSharp/Tests/UseIndexOrRangeOperator/UseRangeOperatorTests.cs
Show resolved
Hide resolved
...alyzers/CSharp/Analyzers/UseIndexOrRangeOperator/CSharpUseRangeOperatorDiagnosticAnalyzer.cs
Outdated
Show resolved
Hide resolved
I attempted to move the if-statement to the ComputeMemberInfo method, however it seems that the necessary information for the IsLeftSideOfAnyAssignExpression() can only been found in the Analyzer, so I decided to keep the if-statement where it was previously.
src/Analyzers/CSharp/Tests/UseIndexOrRangeOperator/UseRangeOperatorTests.cs
Show resolved
Hide resolved
src/Analyzers/CSharp/Tests/UseIndexOrRangeOperator/UseRangeOperatorTests.cs
Show resolved
Hide resolved
|
Copying here to make this clearer: As stated in commit (b08833b) I attempted to move the if-statement to the ComputeMemberInfo method, however it seems that the necessary information for the IsLeftSideOfAnyAssignExpression() can only been found in the Analyzer, so I decided to keep the if-statement where it was previously. |
I addressed the feedback in the comment left above that was requesting changes.
...harp/Analyzers/UseIndexOrRangeOperator/CSharpUseRangeOperatorDiagnosticAnalyzer.InfoCache.cs
Outdated
Show resolved
Hide resolved
| // Second arg needs to be a subtraction for: `end - e2`. Once we've seen that we have | ||
| // that, try to see if we're calling into some sort of Slice method with a matching | ||
| // indexer or overload | ||
| var valid = infoCache.TryGetMemberInfo(targetMethod, out var memberInfo); |
There was a problem hiding this comment.
why was this extracted?
There was a problem hiding this comment.
Just fixed, I had been using valid for something else later but then removed it
…seRangeOperatorDiagnosticAnalyzer.InfoCache.cs Co-authored-by: CyrusNajmabadi <cyrus.najmabadi@gmail.com>
fixes #43202
CC: @JavierMatosD
@sharwell Could you take a look at the changes made to test case "TestNonStringType_Assignment"? The original version seemed to contradict the bug fix we made, but we want to be sure that the test case is not still valid under the new expected behavior.