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.

Sign up for GitHub

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

Add test for F1 on "allows ref struct" #73654

Merged
merged 1 commit into from
May 23, 2024
+13 −0
Merged

Add test for F1 on "allows ref struct" #73654

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions src/VisualStudio/CSharp/Test/F1Help/F1HelpTests.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1474,6 +1474,19 @@ await Test_KeywordAsync(
}", "structconstraint");
}

[Fact, WorkItem("https://github.com/dotnet/roslyn/issues/48392")]
public async Task TestAllowsRefStructAntiConstraint()
{
await Test_KeywordAsync(
@"class C
{
void M<T>()
where T : all[||]ows ref struct
Copy link
Contributor

Choose a reason for hiding this comment

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

ref

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.

Copy link
Contributor Author

@ToddGrun ToddGrun May 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

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)

Copy link
Contributor

Choose a reason for hiding this comment

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

@ToddGrun

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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!

Copy link
Member

Choose a reason for hiding this comment

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

@ToddGrun

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.

{
}
}", "allows");
}

[Fact, WorkItem("https://github.com/dotnet/roslyn/issues/48392")]
public async Task TestUsingStaticOnUsingKeyword()
{
Expand Down
Loading