-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Fix analysis of IOperation descendants for BoundDelegateCreationExpre… #19307
Conversation
…ssion The current IOperation API implementation of BoundDelegateCreationExpression has a bunch of issues and needs to be redesigned. This is tracked by dotnet#8897 and will be addressed post 15.3. Meanwhile, to unblock analyzers on code containing delegate creation expressions with lambda arguments, this bound node has been switched to OperationKind.None with override for Children property. Fixes the first repro case provided in dotnet#8884
Tagging @AlekseyTs @cston @dotnet/analyzer-ioperation for review |
LGTM |
…ng test to account for the change
|
||
public void Method(Delegate d) | ||
{ | ||
var a = /*<bind>*/new Delegate(Method2)/*</bind>*/; |
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.
Method2 [](start = 39, length = 7)
Please add a test with an explicit receiver (a parameter reference, for example). We should get it in the output. #Pending
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.
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.
LGTM
Tagging @MattGertz for ask mode approval. |
…ssion
Customer scenario
Customer uses IOperation analyzers in their code base and see large number of false positives in code with delegate creation expressions taking lambda arguments. For example see #8884 (comment)
Bugs this fixes:
Fixes #8884 (comment)
Workarounds, if any
Customer has to suppress all IOperation analyzers in code containing delegate creation expressions OR disable these analyzers completely.
Risk
Low. We have taken same approach for bunch of other bound nodes that still require IOperation design.
Performance impact
Low.
Is this a regression from a previous update?
No.
Root cause analysis:
The current IOperation API implementation of BoundDelegateCreationExpression has a bunch of issues and needs to be redesigned. This is tracked by #8897 and will be addressed post 15.3. Meanwhile, to unblock analyzers on code containing delegate creation expressions with lambda arguments, this bound node has been switched to OperationKind.None with override for Children property.
How was the bug found?
Dogfooding/customer reports.