Skip to content
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

Update F1 Keywords to differentiate between semantics of default keyword #48500

Merged
merged 11 commits into from
Oct 13, 2020

Conversation

TheSench
Copy link
Contributor

@TheSench TheSench commented Oct 11, 2020

This PR adds two separate f1_keywords for different semantics of the default keyword. This allows the F1 help to route to the appropriate page based on the context, rather than having to route to a generic default page.

The switch-statement version of default is detected by checking if the token is part of a DefaultSwitchLabelSyntax.

The default-value-expression version of default is detected by checking if the token is part of:

  • a DefaultExpressionSyntax (default operator)
  • a LiteralExpressionSyntax (default literal expression)

Fixes part of #48392, dependent on dotnet/docs#20799

Related docs PR:
dotnet/docs#21034

@TheSench TheSench requested a review from a team as a code owner October 11, 2020 11:50
@@ -352,6 +352,20 @@ private static bool TryGetTextForKeyword(SyntaxToken token, ISyntaxFactsService
}
}

if (token.IsKind(SyntaxKind.DefaultKeyword)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (token.IsKind(SyntaxKind.DefaultKeyword)) {
if (token.IsKind(SyntaxKind.DefaultKeyword))
{

return true;
}

if (token.Parent is DefaultExpressionSyntax || token.Parent is LiteralExpressionSyntax)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (token.Parent is DefaultExpressionSyntax || token.Parent is LiteralExpressionSyntax)
if (token.Parent is DefaultExpressionSyntax or LiteralExpressionSyntax)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe or is only valid in VB, isn't it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a new C# 9 feature. See the Pattern Combinators section in dotnet/csharplang#2850

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, I need to get up to speed on C# 9. Thanks for pointing that out.

@davidwengier davidwengier added Area-IDE Community The pull request was submitted by a contributor who is not a Microsoft employee. labels Oct 11, 2020
Comment on lines 363 to 367
if (token.Parent is DefaultExpressionSyntax or LiteralExpressionSyntax)
{
text = Keyword("defaultvalue");
return true;
}
Copy link
Contributor

@davidwengier davidwengier Oct 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this check adding any value? Why not just let this fall through and use default_CSharpKeyword as it currently does? Seems to me like switch labels are the special case here.

Thinking about it more, I'd say just remove the if, set the keyword to defaultvalue and return. I'd probably also put a comment here about why this isn't falling through to default_CSharpKeyword (for older VS versions).

Copy link
Member

@Youssef1313 Youssef1313 Oct 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this check adding any value? Why not just let this fall through and use default_CSharpKeyword as it currently does? Seems to me like switch labels are the special case here.

This is pending a decision on what happens in the docs PR of course.

Falling back to default_CSharpKeyword will lead to maintaining less f1_keywords in docs. So, +1 for that.

This is also what we have done for !, we only introduced one new f1_keyword, and used the existing one as-is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of falling back to the old default_CSharpKeyword, especially now that it no longer is used for the "choose which context" default page.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going this route would require moving the default_CSharpKeyword from the /keywords/default.md page to the /operators/default.md page.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main reason I originally left it in was in case any future usage of default appeared, as it would at least still route to the keyword page. For now though, I'm opting to reuse the existing default_CSharpKeyword and move it to the appropriate page. Does this present any backwards compatibility issues @Youssef1313?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main reason I originally left it in was in case any future usage of default appeared, as it would at least still route to the keyword page. For now though, I'm opting to reuse the existing default_CSharpKeyword and move it to the appropriate page. Does this present any backwards compatibility issues @Youssef1313?

Changes in F1 area in Roslyn will not introduce any backcompat issues.
Changes in docs may introduce backcompat issues if and only if existing f1_keywords are completely deleted.

If a a future usage of default appear, that's not a problem, we can simply update the f1 service and introduce a new f1_keyword for it.

@ghost
Copy link

ghost commented Oct 13, 2020

Hello @davidwengier!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

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 (@msftbot) and give me an instruction to get started! Learn more here.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-approval

@davidwengier
Copy link
Contributor

Thanks for the contribution!

@davidwengier davidwengier merged commit 8746590 into dotnet:master Oct 13, 2020
@ghost ghost added this to the Next milestone Oct 13, 2020
@TheSench TheSench deleted the feature/default-f1-help branch October 13, 2020 10:32
333fred added a commit that referenced this pull request Oct 13, 2020
…features/interpolated-string-constants

* upstream/master: (295 commits)
  Update F1 Keywords to differentiate between semantics of default keyword (#48500)
  Default constructor suggestion between members (#48318) (#48503)
  Adjust ERR_PartialMisplaced diagnostic message (#48524)
  Refactor ChangedText.Merge and add fuzz testing (#48420)
  Apply suggestions from code review
  Do not crash on unexpected exception (#48367)
  Reference the contributing doc in 'Analyzer Suggestion' issue template
  Apply suggestions from code review
  Hardcode skipped Regex diagnostic ID as it is not available in CodeStyle layer
  Add using
  Skip help link for Regex diagnostic analyzer
  Add contributing doc for IDE code style analyzer documentation
  Make db lock static to investigate issue.
  Update dependencies from https://github.com/dotnet/roslyn build 20201012.2 (#48513)
  Hook up help link even for AbstractCodeQualityDiagnosticAnalyzer
  Add destructor intellisense test for record (#48297)
  Remove unused method (#48429)
  Fix bug
  Update src/EditorFeatures/Core.Wpf/InlineHints/InlineHintsTag.cs
  Add more test
  ...
333fred added a commit to 333fred/roslyn that referenced this pull request Oct 13, 2020
* upstream/master: (68 commits)
  Update F1 Keywords to differentiate between semantics of default keyword (dotnet#48500)
  Default constructor suggestion between members (dotnet#48318) (dotnet#48503)
  Adjust ERR_PartialMisplaced diagnostic message (dotnet#48524)
  Refactor ChangedText.Merge and add fuzz testing (dotnet#48420)
  Apply suggestions from code review
  Do not crash on unexpected exception (dotnet#48367)
  Reference the contributing doc in 'Analyzer Suggestion' issue template
  Apply suggestions from code review
  Hardcode skipped Regex diagnostic ID as it is not available in CodeStyle layer
  Add using
  Skip help link for Regex diagnostic analyzer
  Add contributing doc for IDE code style analyzer documentation
  Make db lock static to investigate issue.
  Update dependencies from https://github.com/dotnet/roslyn build 20201012.2 (dotnet#48513)
  Hook up help link even for AbstractCodeQualityDiagnosticAnalyzer
  Add destructor intellisense test for record (dotnet#48297)
  Remove unused method (dotnet#48429)
  Fix bug
  Update src/EditorFeatures/Core.Wpf/InlineHints/InlineHintsTag.cs
  Add more test
  ...
@allisonchou allisonchou modified the milestones: Next, 16.9.P2 Nov 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE Community The pull request was submitted by a contributor who is not a Microsoft employee.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants