Add "related spans" to diagnostic messages

[weswigham]

We already have --pretty error message output, but we can do even better. In this blog post @jonathandturner describes a set of improvements to Rust's error message framework to allow for an error to specify related spans, other than the primary span where the error was encountered - and to provide extra elaboration on each of those spans. This is incredibly useful, and we can do the same.

For example, when we report a duplicate definition error, in the diagnostic object, we could return the spans for the secondary declaration locations in the diagnostics object (potentially with elaboration on how they are a duplicate hidden behind a --elaborate flag). Missing member errors can have a reference back to the type definition (since the error is equally likely to be fixed there). Type errors on assignments can reference back to the declaration of the LHS. There's probably countless errors where we could refer to a secondary location where either a type is likely wrong and causing the error or where the error is likely to be fixed. On the command line, this can just be surfaced as part of the current pretty output, and inside vscode we could potentially coordinate to cause additional related spans to cause a code window to appear in the details popover.

[DanielRosenwasser]

One thing I want is for quick-fixes to operate on related spans as well. For instance, if we fixed #10464, where we'd look for a namespace with the same text as an import path, we would have a related span for the namespace declaration.

I'd imagine a quick fix on the namespace declaration for the actual fix.

[mhegazy]

when we report a duplicate definition error, in the diagnostic object, we could return the spans for the secondary declaration locations in the diagnostics object

this is definitely doable.

type errors on assignments can reference back to the declaration of the LHS. There's probably countless errors where we could refer to a secondary location where either a type is likely wrong and causing the error or where the error is likely to be fixed.

do you have an experience in mind? can you elaborate? how does it look on the command line? do you reference the original declaration all the time? only some types?

and inside vscode we could potentially coordinate to cause additional related spans to cause a code window to appear in the details popover.

this sounds intriguing. specially with VSCode support to click on file names and jump to the location. coupled with some colors this would be a great productivity boost.

[weswigham]

@mhegazy Something along the lines of (to extended on one of the examples from #5140):

8  reticulateSplines() {
.  ~~~~~~~~~~~~~~~~~~~~~
9    let a = 10;
.  ~~~~~~~~~~~~~
...
16   return a + b;
.  ~~~~~~~~~~~~~~~
17  }
.  ~~

hello.ts(8,5): error TS2322 Type '{ reticulateSplines(): number }' is not assignable to type 'I'.
  Object literal may only specify known properties and 'reticulateSplines' does not exist in type 'I'.
  Type '{ reticulateSplines(): number }' inferred from object literal declaration here:
  7  reticulator = {
  .                ~
  8    reticulateSplines() {
  .    ~~~~~~~~~~~~~~~~~~~~~
  ...
  17    }
  .  ~~~~
  18 }
  .  ~
  Type 'I' declared here:
  3 function morphSpline<I extends {reticulateSpline(): number}>(spline: number[], reticulator?: I) {
  .                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Inside vscode, the extended information blocks (Type '{... and Type 'I'... could work well either as hyperlinks to the location or as code windows embedded within the error popover. (Or both!)

[RyanCavanaugh]

Looking for more examples of errors where this would be useful, plus how we would display them on the commandline (or editor) in a useful way

[weswigham]

Looking for more examples of errors where this would be useful

A better, richer way to display the same information #19356 added, for one thing.

[weswigham]

We have these now, and have had them for awhile. 😉