Colorize text in FSharpDiagnostics

[auduchinok]

I propose we use tagged texts in errors/warnings produced by FCS. Below are examples of how it looks for C# in Rider, and it would be nice to do this for F# as well.

Here's a qualified name:

And here's a short name of a method:

It seems especially useful when (longer) signatures are presented (in overload resolution, missing overrides, etc):

This may also be a good community-driven initiative, since it's possible to make separate pull requests for different diagnostics.

[T-Gro]

Could ExtendedDiagnosticData be a mechanism to incrementally roll them out safely ?
Or making it an optional part of every FSharpDiagnostic ?

[auduchinok]

Could ExtendedDiagnosticData be a mechanism to incrementally roll them out safely ?

The extended data is a somewhat different thing: it holds the internal data (types, symbols, etc) that could be used for implementing IDE quick fixes, so I think it's not the best place to place this info to. The change proposed here is only about improving the diagnostic presentation. We could, for example, always create the tagged text instead of the string one and calculate the string version when requested via the Message property.

[T-Gro]

I wonder if an initial MVP could place the tags around all interpolated %s holes ?
To highlight the difference between static text and variable parts.

Something like that could be accomplished more centrally instead of doing this on a case by case basis.

[vzarytovskii]

I wonder if an initial MVP could place the tags around all interpolated %s holes ?
To highlight the difference between static text and variable parts.

Something like that could be accomplished more centrally instead of doing this on a case by case basis.

We support different types of outputs for diagnostics, we technically can add mother which will preserve tags, and for the rest, they will be removed.

[T-Gro]

I am already thinking about an implementation that could be centralized in a single place, rather then spread across code which is now often expecting a (int,string,range) (or similar) and the string is already materialized all over the codebase. (i.e. the substitution of values into holes of a formatted string does not happen centrally, but rather at places where a diagnostic is produced).

[auduchinok]

Something like that could be accomplished more centrally instead of doing this on a case by case basis.

This feature by its nature requires the case by case approach: there's going to be many different cases where we need to highlight things that weren't highlighted previously and this will depend on the symbols/types/context in question. Imagine, for instance, an error that mentions the name of a symbol. Previously only the name itself was required in the text. With this change, we'll have to access the symbol and extract its kind when creating an error instance to highlight it properly. Many diagnostics will indeed be updated in similar ways, but it's still going to be case by case evaluation of how to prepare the needed info.

I think it's fine to update the diagnostics gradually. We should do it for at least couple of different cases so they could be good examples to look at, and then more community members could work on updating the rest.