Update F1 Keywords to differentiate between semantics of default keyword#48500
Update F1 Keywords to differentiate between semantics of default keyword#48500davidwengier merged 11 commits intodotnet:masterfrom
Conversation
There was a problem hiding this comment.
| if (token.IsKind(SyntaxKind.DefaultKeyword)) { | |
| if (token.IsKind(SyntaxKind.DefaultKeyword)) | |
| { |
There was a problem hiding this comment.
| if (token.Parent is DefaultExpressionSyntax || token.Parent is LiteralExpressionSyntax) | |
| if (token.Parent is DefaultExpressionSyntax or LiteralExpressionSyntax) |
There was a problem hiding this comment.
I believe or is only valid in VB, isn't it?
There was a problem hiding this comment.
It's a new C# 9 feature. See the Pattern Combinators section in dotnet/csharplang#2850
There was a problem hiding this comment.
Ahh, I need to get up to speed on C# 9. Thanks for pointing that out.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
Is this check adding any value? Why not just let this fall through and use
default_CSharpKeywordas 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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Going this route would require moving the default_CSharpKeyword from the /keywords/default.md page to the /operators/default.md page.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
The main reason I originally left it in was in case any future usage of
defaultappeared, as it would at least still route to the keyword page. For now though, I'm opting to reuse the existingdefault_CSharpKeywordand 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.
622047f to
245c6f8
Compare
|
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 (
|
|
Thanks for the contribution! |
…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 ...
* 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 ...
This PR adds two separate
f1_keywordsfor 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
defaultis detected by checking if the token is part of aDefaultSwitchLabelSyntax.The default-value-expression version of
defaultis detected by checking if the token is part of:DefaultExpressionSyntax(default operator)LiteralExpressionSyntax(default literal expression)Fixes part of #48392, dependent on dotnet/docs#20799
Related docs PR:
dotnet/docs#21034