No documentation for C# Compiler warning CS8622

BenjaminMichaelis commented 3 years ago

id: CS8622 title: Nullability of reference types in type of parameter doesn't match the target delegate.

I see this was brought up in issue #16954 and saw documentation doesn't exist for it, is this planned on being added at some point?

Looked under https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/ and didn't see it.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: fc586192-534e-0108-d265-c4f2f6947c57
Version Independent ID: 4d39f536-5d78-335b-3525-d4b581c28fdc
Content: C# Compiler Errors
Content Source: docs/csharp/language-reference/compiler-messages/index.md
Product: dotnet-csharp
Technology: csharp-diagnostics
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Youssef1313 commented 3 years ago

Was the other issue closed by error @tdykstra ?

tdykstra commented 3 years ago

Apparently so. I think the closure may have been with intent to consolidate compiler error messages into one issue but I can't find such an issue now.

BillWagner commented 3 years ago

Issue #2363 tracked this project.

It's still a real issue, but we may want to solve it in a different way.

I'm becoming more convinced that a single page for each warning is a bad experience. The introduction of warning waves provides one possible roadmap to a different plan. It's not fully flushed out, and there are higher priority tasks that need to be done first.

In the meantime, any ideas on how to better organize all the information we should provide on compiler errors and warnings would be welcom.

tdykstra commented 3 years ago

What aspects of page-per-warning make it a bad experience?

BillWagner commented 3 years ago

What aspects of page-per-warning make it a bad experience?

The TOC is unwieldy. In addition, it's hard to find related warnings. This will be more important as warning waves are used more often. The titles are the warning, which makes them hard to find on any other search term.

Youssef1313 commented 3 years ago

@BillWagner So should we group multiple errors/warnings together in the same page?

For example, nullable warnings in only one page, etc?

The challenge here is to actually find a suitable groupings.

BenjaminMichaelis commented 3 years ago

@Youssef1313 The only problem I could see about grouping them in one page (I am saying that without knowing fully the backend of how this works but just my brainstormed ideas from a surface level knowledge of the docs implementation) is that

A. It could become convoluted to find a single error on the page depending on how many there are on a page and grouping multiple error/warnings together I assume would be a large undertaking, and

B. in #14691 @BillWagner mentions to connect visual studio to the warning/error pages "Visual Studio sends the token, without any directory information. The token processing service will find the correct article in any folder." so depending on how this service works, it could potentially mess that up as well (once again I know nothing about how the backend of this service actually works), for example if it designed for single pages and not anchors in a larger page and if setting tokens to this is difficult.

tdykstra commented 3 years ago

designed for single pages and not sublinks to a larger page

It is in fact designed for single pages, as the connection is made by putting the warning # in metadata at the top of the page. However, we could put each "warning wave" in a single doc with each warning # in an H2, For any given warning VS would go to the wave doc, and you'd manually select the one you want from the internal TOC. That would make it convenient to browse all the warnings in a warning wave while still being reasonably convenient to go directly to the one you want. And you'd only need one external TOC entry per wave.

AndrewDavid007 commented 3 years ago

In the meantime, the original issue gets lost in your conversation on how to respond. Using Net 5.0 Lets relook at this. When adding a control (Button) to a Form, after double clicking on it to generate code in the associated design .cs file. VS 2022 is generating code that causes this error. Then no explanation of the error is available. I would like to open this issue and get it resolved.

MarcoCaspers commented 3 years ago

designed for single pages and not sublinks to a larger page and you'd manually select the one you want from the internal TOC.

This would be a huge downgrade of the functionality in my opinion. It's not helping items don't exist, but when items do exist having to find them on a large page with a long TOC is not going to make things easier, it's going to make them more difficult. Why not have it that it automatically selects and scrolls to the correct one without me having to meddle with manual searching. You can still display the TOC in a "left column" showing all the errors in the group, so i can still browse others, although i completely fail to see the point. I have error X, so i want all the information about that error, i don't really care about other errors because i'm not having them, so i don't need to see them, even if they are thematically related.

Youssef1313 commented 3 years ago

@OsmondJiang Is it possible for F1 links to go to a specific heading in a page? e.g:

---
f1_keywords:
  - "CS0001#cs0001"
  - "CS0002#cs0002"
---

## CS0001

Content for CS0001

## CS0002

Content for CS0002

BillWagner commented 3 years ago

@NMJCaspers

You make many good points. One reason we haven't made progress here is that we are still considering different options to present the content. We share the same goals: a developer should be able to use the error / warning code to find the answer to fix that issue. They shouldn't have to search, and then use more navigation techniques to find the answer.

OsmondJiang commented 3 years ago

@Youssef1313 @BillWagner

The original F1 service is not designed for this kind of usage, so currently we don't support to specific headings in F1 service. You can talk with our PM @kexugit to file a requirement for that.

Add @yishengjin1413 to this thread who is the new owner of F1 service.

Youssef1313 commented 3 years ago

Actually I think there is no need for changes in F1 service. Roslyn can append the #heading to the F1 service URL and it seems like F1 will append it in the redirected URL correctly. For example, see https://msdn.microsoft.com/query/roslyn.query?appId=roslyn&k=k(await_CSharpKeyword)#await-operator-in-the-main-method works perfectly.

This will require the headings to be "exactly" the error code.

It should be a simple change in Roslyn:

https://github.com/dotnet/roslyn/blob/6884d36627795f1e00303bf4a068dd7998667bd9/src/Compilers/CSharp/Portable/Errors/ErrorFacts.cs#L163

-            return $"https://msdn.microsoft.com/query/roslyn.query?appId=roslyn&k=k({GetId(code)})";
+            var codeId = GetId(code);
+            return $"https://msdn.microsoft.com/query/roslyn.query?appId=roslyn&k=k({codeId})#{codeId}";

What we'd probably need is some guarantee that the current behavior in F1 service doesn't regress. Thoughts @BillWagner @tdykstra ?

BillWagner commented 2 years ago

related to #24002

BillWagner commented 2 years ago

Fixed in #30045

dotnet / docs

No documentation for C# Compiler warning CS8622 #23032

Document Details