Add test for F1 on "allows ref struct" #73654
Conversation
dotnet-issue-labeler
bot
added
Area-IDE
untriaged
| @"class C | ||
| { | ||
| void M<T>() | ||
| where T : all[||]ows ref struct |
There was a problem hiding this comment.
We should add tests for F1 on ref and on struct as well. I am not sure if the keys we get for them today are appropriate for the given context. For example, for a regular struct constraint we go to page for where (https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/where-generic-type-constraint?devlangs=csharp&f1url=%3FappId%3DDev17IDEF1%26l%3DEN-US%26k%3Dk(structconstraint_CSharpKeyword)%3Bk(SolutionItemsProject)%3Bk(SolutionItemsProject)%3Bk(DevLang-csharp)%26rd%3Dtrue), for a struct in struct declaration we go to the page for structure types (https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/struct?devlangs=csharp&f1url=%3FappId%3DDev17IDEF1%26l%3DEN-US%26k%3Dk(struct_CSharpKeyword)%3Bk(SolutionItemsProject)%3Bk(SolutionItemsProject)%3Bk(DevLang-csharp)%26rd%3Dtrue). Perhaps for all the three keywords in allows ref struct we should return the same key that points to a page about allows constraint clause. That could be the page for allows keyword, I guess.
There was a problem hiding this comment.
They are most definitely not appropriate, and it looks like that is a general problem for our F1 support (at least that's what I gathered from the bug that all these tests link to)
There was a problem hiding this comment.
They are most definitely not appropriate, and it looks like that is a general problem for our F1 support (at least that's what I gathered from the bug that all these tests link to)
In this case, I think we should open a dedicated issue for the allows ref struct constraint. We might want to fix that for this feature even if we don't want to spend time to fix that across the board. BTW, as I mentioned we do treat struct keyword specially when it represents a struct type constraint and that points to the right help page. So, it looks like there is a way to achieve the desired behavior.
There was a problem hiding this comment.
We might want to fix that for this feature even if we don't want to spend time to fix that across the board
Can you go ahead and log a bug and we'll have triage decide whether it's worth making these changes? I'm not opposed, I just want to limit the amount of effort I put into F1 support until we validate it's worth the time, given that we've already got a significant amount of debt in this area. Thanks!
There was a problem hiding this comment.
There are two ways to fix the issue where the same token / keyword has multiple uses.
On the docs side, I've created landing pages for keywords that have multiple uses. Here are examples:
Note that the using page has examples. Readers new to C# weren't sure whether to pick "using directive" or "using statement". The examples helped disambiguate for them.
The out keyword is a bit different. It covers the parameter modifier, and links to the generic constraint page.
And, private, protected and internal cover those modifiers, and link to private protected and protected internal as appropriate.
Either fix is fine. We do need to keep the pages and the F1 token used in sync.
It looks like this already detects this is a keyword and sends out a request for allows_CSharpKeyword, which matches the desired value per @BillWagner