Let's explore the potential for greater use of analysis.RelatedInformation for richer and more easily understandable diagnostics.

From Google Issue 332766358:

[@znkr] My main gripe with analyzers is that the smarter they are, the less the error message can explain. ... I wonder if we can do better. Rust and Nushell provide very nice error messages that explain what's going on. I haven't really used Nushell, but the way you create error messages is very simple and results in nice errors: https://www.nushell.sh/book/creating_errors.html
Is that possible with the analyzer framework? Would it be a lot of work to add?

We have the API for it already (analysis.RelatedInformation) but none of our analyzers populate this field because no drivers display it. Actually that's not quite true: gopls passes it directly to the RelatedInformation field in LSP), and then it's up to the client editor to display it however it wants. Of course I don't know what this looks like in practice because none of our analyzers populate it. :) It would be an interesting exercise to see what it looks like in popular editors, and inspect our existing analyzers for opportunities to use this feature to clarify their responses. (Off the top of my head, the lostcancel analyzer always reports an error that relates two source locations, so it would be a good candidate.) Then we would know whether it is worth adding/borrowing/stealing a fancy ASCII-art frontend for the CLI-based drivers. But if some clients just discard this information, there's a disincentive to adapt any analyzer to populate it---a chicken-and-egg situation.

Related:

• x/tools/gopls: use RelatedInformation for diagnostics on interface implementation errors #39062
• x/tools/go/analysis: change RelatedInformation to work without fileset #54233