-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Roslyn analyzer/fixer: Simplify invocations that receive a start/offset and a count/length #35981
Comments
I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label. |
This would apply to AsSpan as well. |
@jeffhandley (or @bartonjs ) when proposing an analyzer, is it sufficient to just label "code-analyzer" and the analyzer crew will see it? Or should there be an "untriaged" column on https://github.com/dotnet/runtime/projects/46 ? |
@danmosemsft We're currently using api-suggestion for that, making it similar to API proposals. |
@bartonjs can we consider this a small improvement over the existing rule, or should we consider it a separate api-suggestion that needs to get approved before I start coding it? I have this other issue opened in the roslyn-analyzers repo to improve over the already merged code: dotnet/roslyn-analyzers#3612 |
If you're tweaking an existing one, that's a tweak. For making a new one (new rule ID, new class, new messages), it's a new one 😄. It seems conceptually easy for a new one; but you should try to describe it like I did in #33763: What is it going to fix? (Description and examples) What is it not going to fix? (Description and samples). E.g.
I think the biggest thing holding back green-lighting a new analyzer is the first bullet... we've already identified that it's not just |
@danmosemsft We aren't yet regularly triaging analyzer suggestions. I intend for us to do a round of triage on them as we're winding down our effort on the ones marked as .NET 5.0. I don't expect to add any more into 5.0 though, so any new suggestions are most likely to be tagged as Future. |
Thanks for the explanation, @bartonjs. Unless there are any objections, I will edit the title and the main description later today, and will explain what is going to be fixed and what is not, per your suggestion. Edit: Ignore my first sentence. There's no point in working on the tweaks for the merged analyzer. This issue should track all cases. |
@jeffhandley sounds good |
Description updated. |
Method calls, or anything involving a member-access expression that isn't a field-access expression, are slightly dangerous to replace, because they could have side effects. Reducing two calls to one can thus change the behavior of a program. That might mean that the fixer batch ID needs to be different for member-access replacement, so someone can bulk apply all of the safe fixes then manually walk through the others. public int GetLength()
{
_callCount++;
return _length;
} |
Summary
Method invocations that receive integer arguments for a start and a length and apply them on an array or a segment, can get the arguments simplified in two specific cases:
Case 1: Exclude both
start
andlength
argumentsConsider this code:
Both
start
andlength
arguments can be removed whenstart = 0
andlength = buffer.Length
:Case 2: Exclude the
length
argumentConsider this code:
The
length
argument can be removed whenstart = offsetValue
andlength = buffer.Length - offsetValue
Method list
The list we know so far is the following (can be expanded):
Examples to detect
For case 1:
The value in the
start
argument can be an integer, a variable, or even a method call, but it must also be part of thelength
argument, as the value being substracted from the length of the array or segment. Examples:The invocations get converted to:
Note: We can discuss if we would like to exclude method calls in the first version of the analyzer, and include it in a future expansion.
For case 2:
A) The value in the
start
argument is 0, and the value in thelength
argument is the length of the array or segment. Examples:The invocations get converted to:
Note: The
Slice
method does not get modified. See the "Examples to not detect" section below for an explanation.Examples to not detect
A) The offset and/or length arguments are saved in variables in previous lines. The initial version of this analyzer should not detect this case, but it can be considered for a future expansion.
For case 1:
For case 2:
B) For case 2, the
Slice
methods must be handled in a special way, since they do not have an overload without arguments. We can exclude this case in the initial version of the analyzer, and we can consider it for future expansions.There are 4 possible routes to take for
Slice
:Slice
invocation removed altogether:Slice
(if such rule does not exist yet).The text was updated successfully, but these errors were encountered: