Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Issue 33798: Prefer Dictionary<K, V>.TryGetValue() over guarded indexer access #4851
Issue 33798: Prefer Dictionary<K, V>.TryGetValue() over guarded indexer access #4851
Changes from 9 commits
894e851
b674f4d
9841f23
5a6205a
736f189
956f654
3f225f9
f458e00
8acc094
ceee42c
86ffe90
f30d613
ee94c98
fb73af1
059fe2c
900d415
cf89a71
174e851
1e0d329
6668bde
8e9d183
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Same as above, do we need
getInnermostNodeForTie
here? If so, needs a test that demonstrates that.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.
We do not, as I still need to access the
InvocationExpressionSyntax
later on.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.
if we do not need
InvocationExpressionSyntax
set, should we remove this?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.
You may want to use the CreateDiagnostic extension method.
https://github.com/dotnet/roslyn-analyzers/blob/0919dbcf9bb03874aec10ec190c2f7f2397c10fb/src/Utilities/Compiler/Extensions/DiagnosticExtensions.cs
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.
Why? What advantages do I gain?
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.
Hm, I think we only want to warn for the Dictionary provided by .Net, no need to warn for any other derived implementations
Correct me if I am wrong @stephentoub
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.
I remember something about the analyzer needing to find derived types as well, but of course can't find any evidence of that now 😅
Would it be a bad thing to catch derived types as well?
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.
I think because they could have different implementation than .Net and might not cause the issue we trying to fix with the analyzer. Though in this case I doubt that the implementation of
ContainsKey+indexer
could avoid double lookup.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.
Good point. So should I remove it, just to be safe?
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.
Actually I think custom implementation of
ContainsKey + indexer
could avoid double lookup. So lets not check derived types to avoid possible false positivesThere 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.
Okay, I'll get on that. This also means that we won't flag a
ContainsKey
on anIDictionary
, right? Most likely the implementation is a .NETDictionary
, however this is not guaranteed. This is unfortunate, since most people (myself included) useIDictionary
when declaring aDictionary
.Also, what about
ConcurrentDictionary
? Do we want to flag that?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.
Good point, most cases the derived types implementation would have same issue, so lets keep checking derived types
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.
Done. I made some changes to increase symbol comparisons, however I am still running into issues when comparing i.e. the
ConcurrentDictionary.ContainsKey
method and theIDictionary.ContainsKey
methods. Even their generic arguments are symbolically different, so the only way I found was to compare signature elements (return type, name and parameters) via string comparison. Is there any way to compare an implemented method to it's interface version more reliably?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.
I would use:
roslyn-analyzers/src/Utilities/Compiler/Extensions/ISymbolExtensions.cs
Line 525 in b2c2cbe