You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We already have --pretty error message output, but we can do even better. In this blog postjonathandturner 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.
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.
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.
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!)
Activity
DanielRosenwasser commentedon Aug 23, 2016
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 commentedon Aug 24, 2016
this is definitely doable.
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?
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 commentedon Sep 9, 2016
Mohamed Hegazy (@mhegazy) Something along the lines of (to extended on one of the examples from #5140):
Inside vscode, the extended information blocks (
Type '{...andType 'I'...could work well either as hyperlinks to the location or as code windows embedded within the error popover. (Or both!)RyanCavanaugh commentedon Sep 28, 2016
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 commentedon Nov 20, 2017
A better, richer way to display the same information #19356 added, for one thing.
weswigham commentedon Nov 6, 2018
We have these now, and have had them for awhile. 😉