-
Notifications
You must be signed in to change notification settings - Fork 4k
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 F1 keywords clashing for !_CSharpKeyword #47516
Conversation
a559cba
to
3db401f
Compare
{ | ||
text = token.Parent.IsKind(SyntaxKind.LogicalNotExpression) | ||
? Keyword("!") | ||
: Keyword("nullForgiving"); |
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.
This feels a little like redoing some of the logic the parser is doing for us already, and will fall down if exclamation points are used for something else in future. For example there is a proposal for argument validation that would use it.
To me it makes more sense to simply check if the parent is SuppressNullableWarningExpression
and return Keyword("nullForgiving")
for that, and let the rest of the code flow as it did before.
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.
@davidwengier I did that in the latest commit but just realized a problem with that approach.
For null forgiving operator, SuppressNullableWarningExpression won't always be the parent.
The parent could be MemberAccessExpression whose parent is SuppressNullableWarningExpression.
So, that will need traversing the tree up to make sure it'll work correctly.
Does it worth doing so?
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.
By the way, I believe there are many other cases that aren't handled correctly. For example, the colon in inheritance vs ternary operator.
Do you see a way to refactor the whole thing instead of keeping special-casing more things? probably make it based on semantics instead of syntax?
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.
The parent could be MemberAccessExpression whose parent is SuppressNullableWarningExpression.
What scenario would have 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.
I looked again in SharpLab and it was just my eyes incorrectly seeing sibling nodes as parent/children 😄 . So this approach should just work.
src/VisualStudio/CSharp/Impl/LanguageService/CSharpHelpContextService.cs
Show resolved
Hide resolved
…Service.cs Co-authored-by: Allison Chou <allichou@microsoft.com>
src/VisualStudio/CSharp/Impl/LanguageService/CSharpHelpContextService.cs
Outdated
Show resolved
Hide resolved
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 with the suggestion sam made.
…Service.cs Co-authored-by: Sam Harwell <sam@tunnelvisionlabs.com>
Hello @davidwengier! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention 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.
Auto-approval
@sharwell @davidwengier Can you re-run the integration tests please? |
I've restarted the leg than hung, and will monitor if it passes (and then if GitHub can be convinced that it has) |
Fixes #46988
@davidwengier Can you review? Also, we should get the docs PR (dotnet/docs#20341) merged first right?