-
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
Classify method group assignments as methods #57410
Classify method group assignments as methods #57410
Conversation
SymbolInfo symbolInfo, | ||
ArrayBuilder<ClassifiedSpan> result) | ||
{ | ||
// If the syntax matches "var x = m" or "x = m", and there is a candidate symbol |
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.
Can we add a test for the "x = m"
scenario?
symbolInfo.CandidateReason == CandidateReason.OverloadResolutionFailure && | ||
symbolInfo.CandidateSymbols[0] is IMethodSymbol methodSymbol) | ||
{ | ||
if (identifierName.IsRightSideOfAnyAssignExpression() || identifierName.IsVariableDeclaratorValue()) |
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.
It is limited only to the bugs I knew about :)
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.
Also, makes me wonder if method-like (Delegate, Action, Func) identifiers should be classified as method names. Totally separate conversation from this tho.
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.
yeah, i agree with jason. i would even simplify this further. if we have a SymbolInfo with an error, and a single candidate, just extract that and classify whatever we have with that symbol.
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 have a SymbolInfo with an error, and a single candidate, just extract that and classify whatever we have with that symbol.
This is a little too broad I think, and breaks a bunch of tests in not good ways. Jason's suggestion only breaks 2 tests, and in ways that seem reasonable to me.
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'm curious what it breaks. Can you clarify?
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.
For example, the two attributes here are classified as classes with the change, which goes against what the comments in the test say.
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.
IMO. THat seems pointless. THe code is in error, and the compiler said: welp... the best thing i can come up with is that they bound to these two symbols (illegally). Things like f12 on the code will then take you to the besft-effort classes.
In those cases, i see no reason why it's a problem for classification to go: yeah... your code is wrong... but it looks like you did bind to these classes, so i'll classify this as a class.
--
In other words... i view the entire endeavor to not classify here very suspect and somewhat of a fools errand :) It's extra work to stop doing a thing that is itself not bad at all :)
if (name is IdentifierNameSyntax identifierName && | ||
symbolInfo.Symbol == null && | ||
symbolInfo.CandidateSymbols.Length == 1 && | ||
symbolInfo.CandidateReason == CandidateReason.OverloadResolutionFailure && |
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.
Should we just count overload resolution as another case that sends us into the ambiguous path here?
roslyn/src/Workspaces/CSharp/Portable/Classification/SyntaxClassification/NameSyntaxClassifier.cs
Lines 72 to 73 in 5256b88
if (symbolInfo.CandidateReason is CandidateReason.Ambiguous or | |
CandidateReason.MemberGroup) |
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.
Thanks for the suggestion, I will give it a try and see what breaks.
There is another spot where I thought a fix could go, where it allows overload resolution to still work for constructors, and I don't know why that wouldn't be the case for any other method, but I always assume that existing behaviour is there for a reason.
This PR is essentially a "is this fix reasonable?" question, because I didn't get an answer on Teams :)
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.
Yeah. All the test changes seem totally reasonable to me.
Thank you for the assistance :) |
* upstream/main: (51 commits) Disable sql when built from source Fix Reduce indirections Reduce indirections Rename files Fix nullability warning Update cloud cache in the same way Ensure only one storage service factory gets created per workspace. Remove processed typename check Simplify Equals method Build CodeAction description into table and only generate Dev17 hash Avoid recomputing expensive persistence location data that does not change. Options Refactoring - Round 3 (dotnet#57254) Merge pull request dotnet#57509 from dotnet/dev/rigibson/fix-publishdata Classify method group assignments as methods (dotnet#57410) Simplify NRT Simplify Remove unnecessary workaround code. Simplify ...
Fixes #57184