Code previews in diagnostics

[gimbling-away]

Is your feature request related to a problem? Please describe.

F#'s diagnostics are currently single-line brief descriptions with a span and a file id.

This is quite tedious, especially if you're actively working with the dotnet CLI through a terminal. It doesn't really give you an insight on where the issue occurs and forces the developer into spawning an editor and finding the location manually.

Describe the solution you'd like

The output containing a preview into the source code, with additional metadata and information pointed across spans. Even in simple cases, this is already quite an improvement. But in more complex cases, it can be particularly helpful.

Consider a hypothetical diagnostic such as this (Image : zesterer/ariadne, diagnostic library in Rust)

But this also inherently supports and encourages better, more supporting diagnostics into the compiler.

(Image : Rustc suggesting the proper keyword to use)

Additional Context

I would be most glad to implement this into the F# compiler. Bringing my (relatively small, but not insignificant) experience working around with Rustc's diagnostics and working with Ariadne into the F# compiler. =)

[baronfel]

The larger problem here is that MSBuild is the one reporting and translating the diagnostics, and there's no facility in MSBuild for 'nice' diagnostics. The MSBuild team (paging @rainersigwald for interest) would love to enable this kind of thing, but there's a multi step process to get there:

• in the MSBuild API for diagnostics expose a way of providing structured data from a diagnostic report (e.g. span ranges that you'd like to highlight for arrows, directives for placeholders in diagnostic text that might want to be highlighted, etc)
• in the MSBuild console logger (we're working on a new, VT-aware one called LiveLogger right now) understand these enhanced diagnostics and print them out in a reasonable way.

separately we have to consider the impact on API consumers of MSBuild diagnostics like VS and VS Code.

[gimbling-away]

separately we have to consider the impact on API consumers of MSBuild diagnostics like VS and VS Code.

I'm not aware of how VS/VSCode currently communicate, but generally the compiler would emit some form of (non-textual, structural) representation and the tooling would consume that?

[baronfel]

yes - you're right that the compilers need to supply all the relevant information as the 'baseline' layer. But from the MSBuild integration perspective, the F# compiler shells out to the CLI version of the compiler, which emits errors in a format that MSBuild can then parse into MSBuild's internal representation of a diagnostic, which MSBuild then emits to the user after yet another transformation. You can see this in the Fsc task in this repo. So that's not ideal from a presentation perspective.

[rainersigwald]

• in the MSBuild API for diagnostics expose a way of providing structured data from a diagnostic report (e.g. span ranges that you'd like to highlight for arrows, directives for placeholders in diagnostic text that might want to be highlighted, etc)

This is a large part of the motivation of dotnet/msbuild#8028, which is being worked on in https://github.com/dotnet/msbuild/pull/8469.

Today, the plan is to support tunneling SARIF through the MSBuild events, for use in structured consumption--with an eye right now on the C++ error experience in the VS UI.

However, if F# (or C# or whatever) were to start populating this data, it would get more interesting to explicitly support it in MSBuild log output (probably in LiveLogger as @baronfel) mentions.