Default and expanded errors for rustc #1644

Merged
merged 14 commits into from Jul 14, 2016

Conversation

Projects
None yet
@jonathandturner
Contributor

jonathandturner commented Jun 7, 2016

Proposed update to the Rust compiler error output format.

rendered (last updated: 6/27/2016 8:30am)

@jonathandturner jonathandturner changed the title from Create 0000-rust-new-error-format.md to Default and expanded errors for rustc Jun 7, 2016

+
+There are a few unresolved questions:
+* Editors that rely on pattern-matching the compiler output will need to be updated. It's an open question how best to transition to using the new errors. There is on-going discussion of standardizing the JSON output, which could also be used.
+* Can additional error notes be shown without the "rainbow problem" where too many colors and too much boldness cause errors to beocome less readable?

This comment has been minimized.

@AndrewBrinker

AndrewBrinker Jun 7, 2016

"beocome" -> "become"

@AndrewBrinker

AndrewBrinker Jun 7, 2016

"beocome" -> "become"

This comment has been minimized.

@ticki

ticki Jun 8, 2016

Contributor

I am sure this is a subjective problem. Some people prefer the colorful approach, others not so much, so I think configurability is the key here.

@ticki

ticki Jun 8, 2016

Contributor

I am sure this is a subjective problem. Some people prefer the colorful approach, others not so much, so I think configurability is the key here.

@petrochenkov

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Jun 7, 2016

Contributor

I'm probably not the main target auditory, but here's one data point.
The green areas is where my sight is usually focused when I look at error messages. The time frame is about few seconds. The rest of the area, especially long explanations, is pretty much noise and is never read.
error_message

EDIT: the red error_message - copy is important though as a visual start marker.

Contributor

petrochenkov commented Jun 7, 2016

I'm probably not the main target auditory, but here's one data point.
The green areas is where my sight is usually focused when I look at error messages. The time frame is about few seconds. The rest of the area, especially long explanations, is pretty much noise and is never read.
error_message

EDIT: the red error_message - copy is important though as a visual start marker.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jun 7, 2016

Contributor

@petrochenkov - thanks! That's actually a really cool analysis. It's totally natural to skip around and only read the parts you want to read.

I don't talk about it much in this RFC, but I did a quick survey of how small number of expert Rust developers used the current error system. Many of them just looked at the line number (and possibly the start of the error message) and ignored the rest. They trusted their ability to debug with just the location in mind.

Being able to be visually parsed as you described is definitely an improvement and to have that much coverage in a few seconds is very promising.

Thanks again.

Contributor

jonathandturner commented Jun 7, 2016

@petrochenkov - thanks! That's actually a really cool analysis. It's totally natural to skip around and only read the parts you want to read.

I don't talk about it much in this RFC, but I did a quick survey of how small number of expert Rust developers used the current error system. Many of them just looked at the line number (and possibly the start of the error message) and ignored the rest. They trusted their ability to debug with just the location in mind.

Being able to be visually parsed as you described is definitely an improvement and to have that much coverage in a few seconds is very promising.

Thanks again.

@bstrie

This comment has been minimized.

Show comment
Hide comment
@bstrie

bstrie Jun 8, 2016

Contributor

I feel like there are two orthogonal RFCs here. We should be able to discuss the new error formatting independently of whether explain should be redesigned.

Contributor

bstrie commented Jun 8, 2016

I feel like there are two orthogonal RFCs here. We should be able to discuss the new error formatting independently of whether explain should be redesigned.

@nrc nrc added the T-dev-tools label Jun 8, 2016

@phil-opp

This comment has been minimized.

Show comment
Hide comment
@phil-opp

phil-opp Jun 8, 2016

IMO the separator of the line number column is a bit noisy. How about just | instead of |>?:

rust-new-error-format-alternative

I think it's less visual clutter and much easier to read, especially the last lines. For example, there is no |> } anymore.

phil-opp commented Jun 8, 2016

IMO the separator of the line number column is a bit noisy. How about just | instead of |>?:

rust-new-error-format-alternative

I think it's less visual clutter and much easier to read, especially the last lines. For example, there is no |> } anymore.

@ticki

This comment has been minimized.

Show comment
Hide comment
@ticki

ticki Jun 8, 2016

Contributor

I agree with @petrochenkov. A lot of it is not relevant at least 90% of the time, but it may be so for new beginners, so having different log-level-esque errors would be very cool.

Contributor

ticki commented Jun 8, 2016

I agree with @petrochenkov. A lot of it is not relevant at least 90% of the time, but it may be so for new beginners, so having different log-level-esque errors would be very cool.

+
+# Alternatives
+
+Rather than using the proposed error format format, we could only provide the verbose --explain style that is proposed in this RFC. Famous programmers like [John Carmack](https://twitter.com/ID_AA_Carmack/status/735197548034412546) have praised the Elm error format.

This comment has been minimized.

@ticki

ticki Jun 8, 2016

Contributor

dybuk is an implementation of something like this.

@ticki

ticki Jun 8, 2016

Contributor

dybuk is an implementation of something like this.

+
+Rather than using the proposed error format format, we could only provide the verbose --explain style that is proposed in this RFC. Famous programmers like [John Carmack](https://twitter.com/ID_AA_Carmack/status/735197548034412546) have praised the Elm error format.
+
+![Image of Elm error](http://www.jonathanturner.org/images/elm_error.jpg)

This comment has been minimized.

@ticki

ticki Jun 8, 2016

Contributor

This image is rather visual trickery. You should make sure that the same colorscheme is used throughout the RFC, to avoid unintended bias.

@ticki

ticki Jun 8, 2016

Contributor

This image is rather visual trickery. You should make sure that the same colorscheme is used throughout the RFC, to avoid unintended bias.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jun 8, 2016

Contributor

@bstrie - possibly, though this lays out what should be default as well (vs say just making the Elm-style the only error output)

Contributor

jonathandturner commented Jun 8, 2016

@bstrie - possibly, though this lays out what should be default as well (vs say just making the Elm-style the only error output)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 8, 2016

Member

I'm pretty excited to see this move forward, I've been using these errors messages on nightly and they're fantastic compared to the old system, and I can't wait to basically just get more of them.

I also really like the idea of --explain going inline with your text and being more descriptive of the code you literally wrote, that seems to be invaluable for learning code quickly as it reduces the path to working code (you just copy/paste what the errors tell you to do) and may help understanding of the rules in abstract over time. Maybe even one day we can have a mode of the compiler that auto-applies all these fancy suggestions and writes your code for you!

One part about removing the error code of --explain though is that we're losing a way to uniquely identify errors. I don't think this is too useful on the command line (kinda annoying to copy/paste), but I've heard it's very useful for googling or search around for solutions others have applied (e.g. when we don't have a suggestion to apply). I wonder if --explain could just expand the error text with a code somewhere in it though? Or maybe we could just unconditionally put the error codes in there all the time somewhere inconspicous (they're pretty small).

My only other thought is that on the removal of "error: aborting due to 2 previous errors" I actually really like seeing the total number of errors that were emitted sometimes. If you do some invasive refactoring and fix everywhere you remembered, this gives a great "progress bar" of how far you have left to go. Maybe that cold be folded into some message elsewhere though? I do agree that the dedicated "error: " line is a bit overkill so I don't really have a preference as to where it shows up so long as it's at the end.

Member

alexcrichton commented Jun 8, 2016

I'm pretty excited to see this move forward, I've been using these errors messages on nightly and they're fantastic compared to the old system, and I can't wait to basically just get more of them.

I also really like the idea of --explain going inline with your text and being more descriptive of the code you literally wrote, that seems to be invaluable for learning code quickly as it reduces the path to working code (you just copy/paste what the errors tell you to do) and may help understanding of the rules in abstract over time. Maybe even one day we can have a mode of the compiler that auto-applies all these fancy suggestions and writes your code for you!

One part about removing the error code of --explain though is that we're losing a way to uniquely identify errors. I don't think this is too useful on the command line (kinda annoying to copy/paste), but I've heard it's very useful for googling or search around for solutions others have applied (e.g. when we don't have a suggestion to apply). I wonder if --explain could just expand the error text with a code somewhere in it though? Or maybe we could just unconditionally put the error codes in there all the time somewhere inconspicous (they're pretty small).

My only other thought is that on the removal of "error: aborting due to 2 previous errors" I actually really like seeing the total number of errors that were emitted sometimes. If you do some invasive refactoring and fix everywhere you remembered, this gives a great "progress bar" of how far you have left to go. Maybe that cold be folded into some message elsewhere though? I do agree that the dedicated "error: " line is a bit overkill so I don't really have a preference as to where it shows up so long as it's at the end.

@AndrewBrinker

This comment has been minimized.

Show comment
Hide comment
@AndrewBrinker

AndrewBrinker Jun 8, 2016

Piggybacking on @alexcrichton's point, I know I've definitely appreciated the searchable error codes before. It makes it a lot easier to find explanations or people with similar situations, and a lot easier to help other people (they can say "I got this error code" and you have a solid sense of what went wrong, very quickly and succinctly).

Piggybacking on @alexcrichton's point, I know I've definitely appreciated the searchable error codes before. It makes it a lot easier to find explanations or people with similar situations, and a lot easier to help other people (they can say "I got this error code" and you have a solid sense of what went wrong, very quickly and succinctly).

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jun 8, 2016

Contributor

@alexcrichton @AndrewBrinker - Definitely agree that keeping it google-able is a good design feature. Rather than using the --explain EXXX pattern, we could just have the error code be part of the error message. Maybe something like:

screen shot 2016-06-08 at 10 07 13 am

(and we could use a similar header for the --explain)

Contributor

jonathandturner commented Jun 8, 2016

@alexcrichton @AndrewBrinker - Definitely agree that keeping it google-able is a good design feature. Rather than using the --explain EXXX pattern, we could just have the error code be part of the error message. Maybe something like:

screen shot 2016-06-08 at 10 07 13 am

(and we could use a similar header for the --explain)

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 8, 2016

Contributor

I think just keeping the codes, without having them be particularly important to explain, makes a lot of sense.

Contributor

nikomatsakis commented Jun 8, 2016

I think just keeping the codes, without having them be particularly important to explain, makes a lot of sense.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 8, 2016

Contributor

(Oh, and I see no reason we can't also tell you the total number of errors while we let you know about --explain)

Contributor

nikomatsakis commented Jun 8, 2016

(Oh, and I see no reason we can't also tell you the total number of errors while we let you know about --explain)

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 8, 2016

Contributor

@bstrie Do you object to the idea of having --explain incorporate parts of the error? It feels like it fits thematically into this RFC -- which is to generally update the "look and feel" over error handling -- and I don't see why we would split it off absent some significant controversy.

For example, @jonathandturner and I spent a while debating whether --explain ought to be the default -- or even if it could be made into the only option! -- which suggests that the two questions (default output, explain output) are quite linked. (We ultimately decided against that, obviously.)

Contributor

nikomatsakis commented Jun 8, 2016

@bstrie Do you object to the idea of having --explain incorporate parts of the error? It feels like it fits thematically into this RFC -- which is to generally update the "look and feel" over error handling -- and I don't see why we would split it off absent some significant controversy.

For example, @jonathandturner and I spent a while debating whether --explain ought to be the default -- or even if it could be made into the only option! -- which suggests that the two questions (default output, explain output) are quite linked. (We ultimately decided against that, obviously.)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 8, 2016

Member

@jonathandturner that looks really good to me! We could maybe toy around with other concepts like:

error[E0455]: cannot borrow `v` as mutable more than once at a time

but that's all in the weeds of bike shedding :). My basic point was that we probably shouldn't jettison error codes even if --explain doesn't take them, and it sounds like we're all on board with that!

@nikomatsakis yeah I also agree it should be trivial to keep the number of errors while we also explain --explain (see what I did there?).

Member

alexcrichton commented Jun 8, 2016

@jonathandturner that looks really good to me! We could maybe toy around with other concepts like:

error[E0455]: cannot borrow `v` as mutable more than once at a time

but that's all in the weeds of bike shedding :). My basic point was that we probably shouldn't jettison error codes even if --explain doesn't take them, and it sounds like we're all on board with that!

@nikomatsakis yeah I also agree it should be trivial to keep the number of errors while we also explain --explain (see what I did there?).

@camlorn

This comment has been minimized.

Show comment
Hide comment
@camlorn

camlorn Jun 8, 2016

Can we please get these as text? I don't know what's being proposed because the RFC only uses images, and images don't read with screen readers.

Will this make errors shorter? I have to scroll the console somewhat often even with 4 or 5 errors. I'd love a nice one or two line output format, but that's probably not what this is.

camlorn commented Jun 8, 2016

Can we please get these as text? I don't know what's being proposed because the RFC only uses images, and images don't read with screen readers.

Will this make errors shorter? I have to scroll the console somewhat often even with 4 or 5 errors. I'd love a nice one or two line output format, but that's probably not what this is.

@ticki

This comment has been minimized.

Show comment
Hide comment
@ticki

ticki Jun 8, 2016

Contributor

@camlorn I will transcribe them for you, two seconds.

Contributor

ticki commented Jun 8, 2016

@camlorn I will transcribe them for you, two seconds.

@ticki

This comment has been minimized.

Show comment
Hide comment
@ticki

ticki Jun 8, 2016

Contributor

@camlorn The first image is the old error format, where the path is written in the start of every line.

The second image is the new format:

error: `self` is not available in a static method. Maybe a `self` argument is missing? [--explain E0424]
  --> vec.rs:94:23
   |>
94 |>         debug_assert!(self.len <= block.size() / mem::size_of::<T>(), "Block not large enough to \
   |>                       ^^^^

The third example describes the long form:

error: cannot move out of borrowed content:
  --> /Users/jturner/Source/errors/borrowck-move-out-of-vec-tail.rs:30:37

I'm trying to track the ownership of the contents of `tail`, which is
borrowed, through this match statement:

29 |>            match tail {

In this match, you use a pattern which will bind to a member of `tail` as a
value. This will move the contents out of `tail`. Because `tail` is
borrowed, you can't safely move the contents:

30 |>              [Foo { string: aa },
   |>                             ^^ cannot move out of borrowed content

You can avoid moving the contents out by using a reference in the pattern, rather
than a move. A naive fix might look like:

30 |>              [Foo { string: ref aa },

The fourth image is the same as the first one. The 6th image is the same as the first one, but with the header (i.e., the error) highlighted. The 7th is the same image again with the line numbers highlighted. The 8th is the same image again with the code span highlighted.

The 9th image is:

error: `Shrinkable` is not a trait [--explain E0404]
 --> rust_error2.rs:5:6
  |>
3 |> type Shrinkable = Growable;
  |> --------------------------- type aliases cannot be used for traits
5 |> impl Shrinkable for i32 { }
  |>      ^^^^^^^^^^ `Shrinkable` is not a trait

The 10th image is the same as the third one. The 11th example is another example of the new format.

The last image is Elm's format:

Detected errors in 1 module.

-- ALIAS PROBLEM ---------------------------------------------- ././Maze.elm

This type alias is recursive, forming an infinite type!

21|>type alias Node =
22|>    { x : Int
23|>    , y : Int
24|>    , children : List Node
25|>    }

When I expand a recursive type alias, it just keeps getting bigger and bigger.
So dealiasing results in an infinitely large type! Try this instead:

    type Node
        = Node { x : Int, y : Int, children : List Node }

This is kind of a subtle distinction. I suggest the naive fix, but you can
often do something a bit nicer. So I would recommend reading more at:
<https://github.com/elm-lang/elm-compiler/blob/0.17.0/hints/recursive-alias.md>

That's all.

Contributor

ticki commented Jun 8, 2016

@camlorn The first image is the old error format, where the path is written in the start of every line.

The second image is the new format:

error: `self` is not available in a static method. Maybe a `self` argument is missing? [--explain E0424]
  --> vec.rs:94:23
   |>
94 |>         debug_assert!(self.len <= block.size() / mem::size_of::<T>(), "Block not large enough to \
   |>                       ^^^^

The third example describes the long form:

error: cannot move out of borrowed content:
  --> /Users/jturner/Source/errors/borrowck-move-out-of-vec-tail.rs:30:37

I'm trying to track the ownership of the contents of `tail`, which is
borrowed, through this match statement:

29 |>            match tail {

In this match, you use a pattern which will bind to a member of `tail` as a
value. This will move the contents out of `tail`. Because `tail` is
borrowed, you can't safely move the contents:

30 |>              [Foo { string: aa },
   |>                             ^^ cannot move out of borrowed content

You can avoid moving the contents out by using a reference in the pattern, rather
than a move. A naive fix might look like:

30 |>              [Foo { string: ref aa },

The fourth image is the same as the first one. The 6th image is the same as the first one, but with the header (i.e., the error) highlighted. The 7th is the same image again with the line numbers highlighted. The 8th is the same image again with the code span highlighted.

The 9th image is:

error: `Shrinkable` is not a trait [--explain E0404]
 --> rust_error2.rs:5:6
  |>
3 |> type Shrinkable = Growable;
  |> --------------------------- type aliases cannot be used for traits
5 |> impl Shrinkable for i32 { }
  |>      ^^^^^^^^^^ `Shrinkable` is not a trait

The 10th image is the same as the third one. The 11th example is another example of the new format.

The last image is Elm's format:

Detected errors in 1 module.

-- ALIAS PROBLEM ---------------------------------------------- ././Maze.elm

This type alias is recursive, forming an infinite type!

21|>type alias Node =
22|>    { x : Int
23|>    , y : Int
24|>    , children : List Node
25|>    }

When I expand a recursive type alias, it just keeps getting bigger and bigger.
So dealiasing results in an infinitely large type! Try this instead:

    type Node
        = Node { x : Int, y : Int, children : List Node }

This is kind of a subtle distinction. I suggest the naive fix, but you can
often do something a bit nicer. So I would recommend reading more at:
<https://github.com/elm-lang/elm-compiler/blob/0.17.0/hints/recursive-alias.md>

That's all.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 8, 2016

Contributor

Interesting. There has also been a discussion around a so-called "traditional" format which would (I think) be something highly condensed of the form

file:line: error: message

and maybe even no additional detail? This would be useful for older
tools that don't really know anything about Rust; it might also help
for screen reader support, I suppose, though you would probably be
interested in having the full details I imagine (i.e., the notes where
a borrow begins and so forth)

On Wed, Jun 08, 2016 at 12:14:45PM -0700, Austin Hicks wrote:

Can we please get these as text? I don't know what's being proposed because the RFC only uses images, and images don't read with screen readers.

Will this make errors shorter? I have to scroll the console somewhat often even with 4 or 5 errors. I'd love a nice one or two line output format, but that's probably not what this is.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1644 (comment)

Contributor

nikomatsakis commented Jun 8, 2016

Interesting. There has also been a discussion around a so-called "traditional" format which would (I think) be something highly condensed of the form

file:line: error: message

and maybe even no additional detail? This would be useful for older
tools that don't really know anything about Rust; it might also help
for screen reader support, I suppose, though you would probably be
interested in having the full details I imagine (i.e., the notes where
a borrow begins and so forth)

On Wed, Jun 08, 2016 at 12:14:45PM -0700, Austin Hicks wrote:

Can we please get these as text? I don't know what's being proposed because the RFC only uses images, and images don't read with screen readers.

Will this make errors shorter? I have to scroll the console somewhat often even with 4 or 5 errors. I'd love a nice one or two line output format, but that's probably not what this is.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1644 (comment)

@ticki

This comment has been minimized.

Show comment
Hide comment
@ticki

ticki Jun 8, 2016

Contributor

I wonder what we can do for people like @camlorn with respect to the error format. @camlorn, what would be your ideal error format?

Contributor

ticki commented Jun 8, 2016

I wonder what we can do for people like @camlorn with respect to the error format. @camlorn, what would be your ideal error format?

@camlorn

This comment has been minimized.

Show comment
Hide comment
@camlorn

camlorn Jun 8, 2016

thanks for the transcription.

As for what we can do generally? Convince Microsoft to let me set the font in the console even smaller. I don't need readable...

More seriously...

This is an opinion. I'm kind of unique in a lot of ways, not least that I'm one of the few blind people who considers C++ easy. My considerations may not be the considerations of a new blind programmer.

Firstly, we don't need --explain for advanced rust people. This takes terminal space. I know it exists. Reminding me of it is just an annoying thing to read. Obviously it needs to be on by default, but turning it off somehow would be nice. We could move the error code to be in brackets after the line numbers, or just in brackets after the message.

Prefixing with |> is pretty much the same as prefixing with ///. All my comments on the "Only allow /// for docs" rfc apply here: it's annoying but readable if I have to.

The underlines to show where the error is are useless completely. I don't think there's a particularly good solution unless we have a character which will be always reserved. If we did, we could surround the error with it in the same manner that you use parens. As it stands, I'd like to murder the underlines in the most painful way possible and not only for Rust. Surrounding the error's source with something might actually be helpful.

I've never quite used the information on borrow scopes. I don't know why. I think that part of it is that reading code in the terminal is inconvenient. I also find that my C++ experience puts me in a good place to reason about lifetimes.

Showing the surrounding code is not helpful. If I want to see the surrounding code, I'll use go to line in my editor. I think this one is a fundamental difference between blind and sighted people. There is no way for me to glance at anything, so the cost of reading the code in the terminal and then reading the code in the editor is about twice that of just using the editor. If I have to scroll to see it, it's more. If we can find a way to emphasize the error, showing the code for the error might be useful.

If I had to make a suggestion, provide the line numbers of the borrow regions, possibly with the text of the line. This might be { and } in practice, so that might not be so useful.

If we assume that this is a hypothetical terse error mode that you explicitly enable with an environment variable, you could have a switch to explicitly disable it. In that case, if I need the information in the expanded version, I can still get it.

Sorry I can't speak more definitely. I started a large project in Rust, but the larger project in C++ took priority for now. This means that I don't have enough experience to have a workflow that's a procedure as such. With the C++ compiler, I could document exactly what I press because it's always the same. With Rust, it's not quite to the level of mechanical procedure yet.

camlorn commented Jun 8, 2016

thanks for the transcription.

As for what we can do generally? Convince Microsoft to let me set the font in the console even smaller. I don't need readable...

More seriously...

This is an opinion. I'm kind of unique in a lot of ways, not least that I'm one of the few blind people who considers C++ easy. My considerations may not be the considerations of a new blind programmer.

Firstly, we don't need --explain for advanced rust people. This takes terminal space. I know it exists. Reminding me of it is just an annoying thing to read. Obviously it needs to be on by default, but turning it off somehow would be nice. We could move the error code to be in brackets after the line numbers, or just in brackets after the message.

Prefixing with |> is pretty much the same as prefixing with ///. All my comments on the "Only allow /// for docs" rfc apply here: it's annoying but readable if I have to.

The underlines to show where the error is are useless completely. I don't think there's a particularly good solution unless we have a character which will be always reserved. If we did, we could surround the error with it in the same manner that you use parens. As it stands, I'd like to murder the underlines in the most painful way possible and not only for Rust. Surrounding the error's source with something might actually be helpful.

I've never quite used the information on borrow scopes. I don't know why. I think that part of it is that reading code in the terminal is inconvenient. I also find that my C++ experience puts me in a good place to reason about lifetimes.

Showing the surrounding code is not helpful. If I want to see the surrounding code, I'll use go to line in my editor. I think this one is a fundamental difference between blind and sighted people. There is no way for me to glance at anything, so the cost of reading the code in the terminal and then reading the code in the editor is about twice that of just using the editor. If I have to scroll to see it, it's more. If we can find a way to emphasize the error, showing the code for the error might be useful.

If I had to make a suggestion, provide the line numbers of the borrow regions, possibly with the text of the line. This might be { and } in practice, so that might not be so useful.

If we assume that this is a hypothetical terse error mode that you explicitly enable with an environment variable, you could have a switch to explicitly disable it. In that case, if I need the information in the expanded version, I can still get it.

Sorry I can't speak more definitely. I started a large project in Rust, but the larger project in C++ took priority for now. This means that I don't have enough experience to have a workflow that's a procedure as such. With the C++ compiler, I could document exactly what I press because it's always the same. With Rust, it's not quite to the level of mechanical procedure yet.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jun 8, 2016

Contributor

I like the direction of this RFC generally.

--explain is a stable compiler interface. How can we change it? I agree that --explain is a sweet name for this functionality, but I think we need to use a different one.

It's not clear to me what the fate of error codes is here. My impression is that you are proposing to remove them, but your images contain the current --explain E0002. Can you make this more clear, and if you are removing error codes can you remove them from the graphics?

"Famous programmers like John Carmack have praised the Elm error format."

John Carmack's fame doesn't really have any bearing on the validity of the proposal.

Also, I don't think RFCs should be giving props to other contributors in the summary. When creating the RFC process we made an explicit decision not to include author information, to avoid making RFC authorship itself an incentive (I think). If authorship is something that should be included in RFCs then the process itself should be modified to include that metadata, including crediting the actual author, not just their collaborators. If giving credit in the RFC text is something we want to encourage, then I don't know that the summary is the place for it. The summary is for summarizing the content of the RFC.

Contributor

brson commented Jun 8, 2016

I like the direction of this RFC generally.

--explain is a stable compiler interface. How can we change it? I agree that --explain is a sweet name for this functionality, but I think we need to use a different one.

It's not clear to me what the fate of error codes is here. My impression is that you are proposing to remove them, but your images contain the current --explain E0002. Can you make this more clear, and if you are removing error codes can you remove them from the graphics?

"Famous programmers like John Carmack have praised the Elm error format."

John Carmack's fame doesn't really have any bearing on the validity of the proposal.

Also, I don't think RFCs should be giving props to other contributors in the summary. When creating the RFC process we made an explicit decision not to include author information, to avoid making RFC authorship itself an incentive (I think). If authorship is something that should be included in RFCs then the process itself should be modified to include that metadata, including crediting the actual author, not just their collaborators. If giving credit in the RFC text is something we want to encourage, then I don't know that the summary is the place for it. The summary is for summarizing the content of the RFC.

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Jun 8, 2016

Contributor

At the very least we should have a fully working json error output, which one could pass through an arbitrary filter of the form rustc >/dev/null 2>&1 | awesome_error_printer and thus making it possible to make rust output accessible, even if not by default. Sure that doesn’t change the fact about default experience being junk for people with special needs, but at least there would be an option, however minuscule.

Contributor

nagisa commented Jun 8, 2016

At the very least we should have a fully working json error output, which one could pass through an arbitrary filter of the form rustc >/dev/null 2>&1 | awesome_error_printer and thus making it possible to make rust output accessible, even if not by default. Sure that doesn’t change the fact about default experience being junk for people with special needs, but at least there would be an option, however minuscule.

@ticki

This comment has been minimized.

Show comment
Hide comment
@ticki

ticki Jun 9, 2016

Contributor

@camlorn @nagisa We should have a ACESSIBLITY_MODE variable.

Contributor

ticki commented Jun 9, 2016

@camlorn @nagisa We should have a ACESSIBLITY_MODE variable.

@nielsle

This comment has been minimized.

Show comment
Hide comment
@nielsle

nielsle Jun 9, 2016

I think that it would be helpful for newbies to spend an entire sentence to introduce --explain E040

error: `Shrinkable` is not a trait [E040]
--> rust_error2.rs:5:6
  |>
3 |> type Shrinkable = Growable;
  |> --------------------------- type aliases cannot be used for traits
5 |> impl Shrinkable for i32 { }
  |>      ^^^^^^^^^^ `Shrinkable` is not a trait
For a detailed description of the error  type: rustc --explain E040

It would be great to have an ACESSIBILITY_MODE. Perhaps it could also control warnings about unoptimized builds #967.

nielsle commented Jun 9, 2016

I think that it would be helpful for newbies to spend an entire sentence to introduce --explain E040

error: `Shrinkable` is not a trait [E040]
--> rust_error2.rs:5:6
  |>
3 |> type Shrinkable = Growable;
  |> --------------------------- type aliases cannot be used for traits
5 |> impl Shrinkable for i32 { }
  |>      ^^^^^^^^^^ `Shrinkable` is not a trait
For a detailed description of the error  type: rustc --explain E040

It would be great to have an ACESSIBILITY_MODE. Perhaps it could also control warnings about unoptimized builds #967.

@camlorn

This comment has been minimized.

Show comment
Hide comment
@camlorn

camlorn Jun 9, 2016

What solves the problem generally is the ability to just write custom error templates. My accessible mode is probably not the next person's accessible mode, and I think that more blind people need to be programming in Rust before we can go there. Unfortunately, I don't think this is likely to happen anytime soon. I might be the only one.

I don't like the idea of piping through a script. Json error output could be useful for other reasons. I suppose that it can somehow be hacked together, but Windows scripting support is really not so great. And also whatever you write will have to deal with cargo output too.

The easiest way to make this immediately better is to let me configure the number of errors to show. If you set it to 2 instead of 5, then the terminal doesn't scroll. I'm going to also make a point of asking the head dev of my screen reader if automatic scrolling is possible. This doesn't fix the issue of a lot of noise and extra lines that I have to arrow past, but it does fix needing to press a ton of extra stuff to just move the console up a page. This also looks like it might be a bit shorter, so it's possible it'll fix that part of it on it's own.

I'm not really concerned about it. It could be better. But Rust is far from the top of the list of inaccessible things that make my life with technology harder.

camlorn commented Jun 9, 2016

What solves the problem generally is the ability to just write custom error templates. My accessible mode is probably not the next person's accessible mode, and I think that more blind people need to be programming in Rust before we can go there. Unfortunately, I don't think this is likely to happen anytime soon. I might be the only one.

I don't like the idea of piping through a script. Json error output could be useful for other reasons. I suppose that it can somehow be hacked together, but Windows scripting support is really not so great. And also whatever you write will have to deal with cargo output too.

The easiest way to make this immediately better is to let me configure the number of errors to show. If you set it to 2 instead of 5, then the terminal doesn't scroll. I'm going to also make a point of asking the head dev of my screen reader if automatic scrolling is possible. This doesn't fix the issue of a lot of noise and extra lines that I have to arrow past, but it does fix needing to press a ton of extra stuff to just move the console up a page. This also looks like it might be a bit shorter, so it's possible it'll fix that part of it on it's own.

I'm not really concerned about it. It could be better. But Rust is far from the top of the list of inaccessible things that make my life with technology harder.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jun 9, 2016

Contributor

@jonathandturner my comments could have been more constructive. Let me respond to myself.

"Famous programmers like John Carmack have praised the Elm error format."

John Carmack's fame doesn't really have any bearing on the validity of the proposal.

Maybe just change 'fame' to something more relevant, like 'well-respected', something that better indicates why his opinion is important.

Also, I don't think RFCs should be giving props to other contributors in the summary. When creating the RFC process we made an explicit decision not to include author information, to avoid making RFC authorship itself an incentive (I think). If authorship is something that should be included in RFCs then the process itself should be modified to include that metadata, including crediting the actual author, not just their collaborators. If giving credit in the RFC text is something we want to encourage, then I don't know that the summary is the place for it. The summary is for summarizing the content of the RFC.

I phrased this too strongly. I just had a sudden observation that we've developed ad-hoc ways to credit people that doesn't fit into the process as implemented. I should have phrased this more like 'maybe we should reconsider how to give credit in RFCs'. RFC process is organic so it may be perfectly fine to do it like this (author credit in the commit log, additional credits in the summary), but it is awkward. And I do believe we made an intentional decision not to credit people, and if that is changing it is important to acknowledge it.

Contributor

brson commented Jun 9, 2016

@jonathandturner my comments could have been more constructive. Let me respond to myself.

"Famous programmers like John Carmack have praised the Elm error format."

John Carmack's fame doesn't really have any bearing on the validity of the proposal.

Maybe just change 'fame' to something more relevant, like 'well-respected', something that better indicates why his opinion is important.

Also, I don't think RFCs should be giving props to other contributors in the summary. When creating the RFC process we made an explicit decision not to include author information, to avoid making RFC authorship itself an incentive (I think). If authorship is something that should be included in RFCs then the process itself should be modified to include that metadata, including crediting the actual author, not just their collaborators. If giving credit in the RFC text is something we want to encourage, then I don't know that the summary is the place for it. The summary is for summarizing the content of the RFC.

I phrased this too strongly. I just had a sudden observation that we've developed ad-hoc ways to credit people that doesn't fit into the process as implemented. I should have phrased this more like 'maybe we should reconsider how to give credit in RFCs'. RFC process is organic so it may be perfectly fine to do it like this (author credit in the commit log, additional credits in the summary), but it is awkward. And I do believe we made an intentional decision not to credit people, and if that is changing it is important to acknowledge it.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jun 10, 2016

Contributor

@phil-opp - we'd tried the single | rather than the |> early on but had shied away from it because at the time it wasn't quite enough. Since then, we've spaced things out a little more, which makes it possible.

I made the fix on my local build, and I agree it is nicer.

screen shot 2016-06-10 at 7 54 07 am

@brson - good point re: --explain backward compatibility. Perhaps we should use --detailed or --error_format=detailed. Happy to move out the acknowledgements until we settled on a way to give credit.

@AndrewBrinker / @alexcrichton - yes, lets definitely keep the error codes for google-ability. I kinda like alex's suggestion of putting it beside error (like "error[E0123]: the error message")

@ticki - thanks for typing all that out :)

Contributor

jonathandturner commented Jun 10, 2016

@phil-opp - we'd tried the single | rather than the |> early on but had shied away from it because at the time it wasn't quite enough. Since then, we've spaced things out a little more, which makes it possible.

I made the fix on my local build, and I agree it is nicer.

screen shot 2016-06-10 at 7 54 07 am

@brson - good point re: --explain backward compatibility. Perhaps we should use --detailed or --error_format=detailed. Happy to move out the acknowledgements until we settled on a way to give credit.

@AndrewBrinker / @alexcrichton - yes, lets definitely keep the error codes for google-ability. I kinda like alex's suggestion of putting it beside error (like "error[E0123]: the error message")

@ticki - thanks for typing all that out :)

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jun 10, 2016

Contributor

@camlorn - I'm currently working on a refactor of error reporting into its own crate that should make it easier to configure your error messages. I'd planned to support a 'default' (the proposed error with underlines), 'expanded' (the proposed new --explain), and 'json'. Once the refactor is in place it should be straightforward to add a format that's more friendly to screen readers.

Thanks for your detailed description of a screen reader-friendly error format. I suspect you would not be the only person to use it, and that other people would also find it useful. To make sure I understand, would the format be something like this in practice?

error[E0499]: cannot borrow `*x` as mutable more than once at a time at src/test/compile-fail/borrowck/borrowck-borrow-mut-object-twice.rs:21:5
error: "second mutable borrow occurs here" at 21:4
note: "first mutable borrow occurs here" at 20:13
note: "first bottow ends here" at 22:1

I'd love to brainstorm/iterate on putting together a more compact, reader-friendly format.

Contributor

jonathandturner commented Jun 10, 2016

@camlorn - I'm currently working on a refactor of error reporting into its own crate that should make it easier to configure your error messages. I'd planned to support a 'default' (the proposed error with underlines), 'expanded' (the proposed new --explain), and 'json'. Once the refactor is in place it should be straightforward to add a format that's more friendly to screen readers.

Thanks for your detailed description of a screen reader-friendly error format. I suspect you would not be the only person to use it, and that other people would also find it useful. To make sure I understand, would the format be something like this in practice?

error[E0499]: cannot borrow `*x` as mutable more than once at a time at src/test/compile-fail/borrowck/borrowck-borrow-mut-object-twice.rs:21:5
error: "second mutable borrow occurs here" at 21:4
note: "first mutable borrow occurs here" at 20:13
note: "first bottow ends here" at 22:1

I'd love to brainstorm/iterate on putting together a more compact, reader-friendly format.

@ticki

This comment has been minimized.

Show comment
Hide comment
@ticki

ticki Jun 10, 2016

Contributor

@camlorn @jonathandturner I am currently working on a "demand-driven" error formatter for blind people. A session would look like this:

Error in line 245
show
cannot move out of borrowed context.
code
      self.move()
next
Error in line 247
show
cannot borrow `*x` as mutable more than once at a time
recompile

I would like your input on this @camlorn.

I try to avoid sign clutter, so there's no e.g. $ in the command prompt, possibly making it more screen-reader friendly.

Contributor

ticki commented Jun 10, 2016

@camlorn @jonathandturner I am currently working on a "demand-driven" error formatter for blind people. A session would look like this:

Error in line 245
show
cannot move out of borrowed context.
code
      self.move()
next
Error in line 247
show
cannot borrow `*x` as mutable more than once at a time
recompile

I would like your input on this @camlorn.

I try to avoid sign clutter, so there's no e.g. $ in the command prompt, possibly making it more screen-reader friendly.

@brendanzab

This comment has been minimized.

Show comment
Hide comment
@brendanzab

brendanzab Jun 15, 2016

Member

I would thumbs-up the new error format, but the fact that it has been linked with the --explain suggestion prevents me from doing so. I've been using the new error messages by default this past month and find it very jarring to go back! I'm very happy with the work that has been done!

Echoing @alexcrichton - I would love to see the total error/warning counts restored - I find them a nice way to see your progress when working through a refactor.

Member

brendanzab commented Jun 15, 2016

I would thumbs-up the new error format, but the fact that it has been linked with the --explain suggestion prevents me from doing so. I've been using the new error messages by default this past month and find it very jarring to go back! I'm very happy with the work that has been done!

Echoing @alexcrichton - I would love to see the total error/warning counts restored - I find them a nice way to see your progress when working through a refactor.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 16, 2016

Contributor

@bjz

I would thumbs-up the new error format, but the fact that it has been linked with the --explain suggestion prevents me from doing so.

Can you expand a bit here? Are you saying that you think it's better to have --explain continue to be "canned" text, withholding judgement until you see something more concrete, or something else entirely?

Contributor

nikomatsakis commented Jun 16, 2016

@bjz

I would thumbs-up the new error format, but the fact that it has been linked with the --explain suggestion prevents me from doing so.

Can you expand a bit here? Are you saying that you think it's better to have --explain continue to be "canned" text, withholding judgement until you see something more concrete, or something else entirely?

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 27, 2016

Member

Updates all look fantastic to me, thanks @jonathandturner!

should the new error format be turned on by default or should we have a process of verifying and validating and only then make it the default?

I would personally advocate for one cycle of behind the env var we have today, and then if it all looks good ungate it after that cycle

Member

alexcrichton commented Jun 27, 2016

Updates all look fantastic to me, thanks @jonathandturner!

should the new error format be turned on by default or should we have a process of verifying and validating and only then make it the default?

I would personally advocate for one cycle of behind the env var we have today, and then if it all looks good ungate it after that cycle

@nrc nrc self-assigned this Jun 28, 2016

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 29, 2016

Contributor

Nice work @jonathandturner on the revisions. 👍 from me.

Contributor

nikomatsakis commented Jun 29, 2016

Nice work @jonathandturner on the revisions. 👍 from me.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jun 30, 2016

Contributor

Great. Sounds like this thing is ready to go to FCP, so let's start FCP (unless there are any objections).

I'm fine with @alexcrichton's suggestion of being behind a flag for a cycle.

Contributor

jonathandturner commented Jun 30, 2016

Great. Sounds like this thing is ready to go to FCP, so let's start FCP (unless there are any objections).

I'm fine with @alexcrichton's suggestion of being behind a flag for a cycle.

+- Rust Issue: (leave this empty)
+
+# Summary
+This RFC proposes an update to error reporting in rustc. Its focus is to change the format of Rust error messages and improve --explain capabilities to focus on the user's code. The end goal is for errors and explain text to be more readable, more friendly to new users, while still helping Rust coders fix bugs as quickly as possible. We expect to follow this RFC with a supplemental RFC that provides a writing style guide for error messages and explain text with a focus on readability and education.

This comment has been minimized.

@nrc

nrc Jul 4, 2016

Member

nit: could you wrap at 80 chars please (I'm sure this was specified somewhere, but maybe it is just a de facto thing that people do?)

@nrc

nrc Jul 4, 2016

Member

nit: could you wrap at 80 chars please (I'm sure this was specified somewhere, but maybe it is just a de facto thing that people do?)

+```
+
+[as image]
+![Image of new error flow](http://www.jonathanturner.org/images/old_errors_3.png)

This comment has been minimized.

@nrc

nrc Jul 4, 2016

Member

nit: alt text is incorrect (this is the old errors, not the new ones, right?). Also I don't think you need the [as text]/[as image] tags - GH renders them as text.

@nrc

nrc Jul 4, 2016

Member

nit: alt text is incorrect (this is the old errors, not the new ones, right?). Also I don't think you need the [as text]/[as image] tags - GH renders them as text.

+
+Key parts of the code are labeled with messages to help the user understand the message.
+
+The primary label is the label associated with the main warning/error. It explains the **what** of the compiler message. By reading it, the user can begin to understand what the root cause of the error or warning is. This label is colored to match the level of the message (yellow for warning, red for error) and uses the ^^^ underline.

This comment has been minimized.

@nrc

nrc Jul 4, 2016

Member

Could the error label be standard weight text rather than bold? One problem I have with the new messages is all the bold text - it makes the really important stuff (which should be bold) harder to pick out and (in my console at least) the bold text is quite a bit harder to read than standard weight.

@nrc

nrc Jul 4, 2016

Member

Could the error label be standard weight text rather than bold? One problem I have with the new messages is all the bold text - it makes the really important stuff (which should be bold) harder to pick out and (in my console at least) the bold text is quite a bit harder to read than standard weight.

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Jul 4, 2016

Member

I like the error format changes a lot and approve this RFC. However, the changes to explain seem like they could do with some experimentation before they get RFC'ed. I don't think we need an RFC to do that experimentation and I think an eventual RFC would benefit from having the experimentation done first.

While we do RFC language features before implementation, it is a bit weird to have a two-part RFC with half implemented and iterated upon, and half speculative.

Member

nrc commented Jul 4, 2016

I like the error format changes a lot and approve this RFC. However, the changes to explain seem like they could do with some experimentation before they get RFC'ed. I don't think we need an RFC to do that experimentation and I think an eventual RFC would benefit from having the experimentation done first.

While we do RFC language features before implementation, it is a bit weird to have a two-part RFC with half implemented and iterated upon, and half speculative.

+error: cannot move out of borrowed content
+ --> /Users/jturner/Source/errors/borrowck-move-out-of-vec-tail.rs:30:17
+
+I’m trying to track the ownership of the contents of `tail`, which is borrowed, through this match statement:

This comment has been minimized.

@nrc

nrc Jul 4, 2016

Member

This first-person, conversational style drives me nuts. I find it patronising and hard to comprehend. AFAIK there is only one other language that does this and there is no evidence that it is in any way better than traditional style.

@nrc

nrc Jul 4, 2016

Member

This first-person, conversational style drives me nuts. I find it patronising and hard to comprehend. AFAIK there is only one other language that does this and there is no evidence that it is in any way better than traditional style.

This comment has been minimized.

@jonathandturner

jonathandturner Jul 4, 2016

Contributor

Thanks for the feedback. I should have probably reiterated again in this section that this RFC's focus is the error format, not the error writing style. The way these errors are written will be a follow-up RFC as we get more experience with what works best.

I list some evidence, by way of mentioning it being praised by noted programmers, but anecdotally, I've been watching the feedback from other programmers around the web. They praise the elm style for being a) one of the best error message styles, b) so thorough they use it as a way to pick back up an editing session if it's cut short on a train ride, c) more new user-friendly than other error styles.

Note, too, that we're not saying that the expanded style is better for all users, but rather it's one we should support for users who wish to have more information. Some users may enable --explain errors and leave it on for all projects, and that would be fine, while others may prefer more compact formats.

@jonathandturner

jonathandturner Jul 4, 2016

Contributor

Thanks for the feedback. I should have probably reiterated again in this section that this RFC's focus is the error format, not the error writing style. The way these errors are written will be a follow-up RFC as we get more experience with what works best.

I list some evidence, by way of mentioning it being praised by noted programmers, but anecdotally, I've been watching the feedback from other programmers around the web. They praise the elm style for being a) one of the best error message styles, b) so thorough they use it as a way to pick back up an editing session if it's cut short on a train ride, c) more new user-friendly than other error styles.

Note, too, that we're not saying that the expanded style is better for all users, but rather it's one we should support for users who wish to have more information. Some users may enable --explain errors and leave it on for all projects, and that would be fine, while others may prefer more compact formats.

This comment has been minimized.

@nrc

nrc Jul 5, 2016

Member

To clarify, I didn't mean the style of integrating user code and error mesage, I meant the style of using first and second person pronouns and anthropomorphisation of the compiler, rather than a more academic tone.

@nrc

nrc Jul 5, 2016

Member

To clarify, I didn't mean the style of integrating user code and error mesage, I meant the style of using first and second person pronouns and anthropomorphisation of the compiler, rather than a more academic tone.

This comment has been minimized.

@jonathandturner

jonathandturner Jul 5, 2016

Contributor

Right, that's why I say "We expect to follow this RFC with a supplemental RFC that provides a writing style guide for error messages and explain text with a focus on readability and education." in the RFC. The writing style will need to be a separate RFC.

@jonathandturner

jonathandturner Jul 5, 2016

Contributor

Right, that's why I say "We expect to follow this RFC with a supplemental RFC that provides a writing style guide for error messages and explain text with a focus on readability and education." in the RFC. The writing style will need to be a separate RFC.

+
+Inspired by Dybuk and Elm, the line numbers are separated with a 'wall', a separator formed from pipe('|') characters, to clearly distinguish what is a line number from what is source at a glance.
+
+As the wall also forms a way to visually separate distinct errors, we propose extending this concept to also support span-less notes and hints. For example:

This comment has been minimized.

@nrc

nrc Jul 4, 2016

Member

I don't understand this. AIUI, the point of the code-oriented layout is that multiple notes ('sub-errors') on the same block of code are displayed together and inline. So the wall ties the errors together rather than separates them out.

In the example below, I'm not sure what is being communicated by the = (which, bikeshed, I'm not a fan of because it is so commonly used in code) - are the notes meant to be tied to the walled source or distinct from it? If the former then this seems to imply that the notes come logically at the end of the code, but in fact they might in general be related to an error in the middle of the displayed lines of codes.

On a purely aesthetic level, I'm not sure if <indent>= note... either makes the notes more distinct or more tied to the walled code (c.f., <no indent> note..., but (to me) it does read as more 'line-noisey'.

@nrc

nrc Jul 4, 2016

Member

I don't understand this. AIUI, the point of the code-oriented layout is that multiple notes ('sub-errors') on the same block of code are displayed together and inline. So the wall ties the errors together rather than separates them out.

In the example below, I'm not sure what is being communicated by the = (which, bikeshed, I'm not a fan of because it is so commonly used in code) - are the notes meant to be tied to the walled source or distinct from it? If the former then this seems to imply that the notes come logically at the end of the code, but in fact they might in general be related to an error in the middle of the displayed lines of codes.

On a purely aesthetic level, I'm not sure if <indent>= note... either makes the notes more distinct or more tied to the walled code (c.f., <no indent> note..., but (to me) it does read as more 'line-noisey'.

This comment has been minimized.

@jonathandturner

jonathandturner Jul 4, 2016

Contributor

There are multiple kinds of notes, the knowledge of which I unfortunately assume in a few places. Hints, suggestions, notes, etc can all be associated with an error message. Notes (and the like) which do not have span information need to still be associated with the error. They're less common now that many notes are becoming labels, but they still exist in a few cases. Where un-spanned notes are associated with an error, I suggest printing them at the bottom of the error block.

A bit of backstory here. In a previous iteration of the design (currently in nightly), they are left-aligned and colored. @alexcrichton showed us some examples at one point where he was getting a lot of error messages in a row, all with unspanned notes. The result had a negative impact on readability because it was harder to discern each separate error. In this version of the format, we group unspanned notes and indent them so your eye can see a whole error message as a single group, by skipping the indented line and looking for where the next message starts.

@jonathandturner

jonathandturner Jul 4, 2016

Contributor

There are multiple kinds of notes, the knowledge of which I unfortunately assume in a few places. Hints, suggestions, notes, etc can all be associated with an error message. Notes (and the like) which do not have span information need to still be associated with the error. They're less common now that many notes are becoming labels, but they still exist in a few cases. Where un-spanned notes are associated with an error, I suggest printing them at the bottom of the error block.

A bit of backstory here. In a previous iteration of the design (currently in nightly), they are left-aligned and colored. @alexcrichton showed us some examples at one point where he was getting a lot of error messages in a row, all with unspanned notes. The result had a negative impact on readability because it was harder to discern each separate error. In this version of the format, we group unspanned notes and indent them so your eye can see a whole error message as a single group, by skipping the indented line and looking for where the next message starts.

This comment has been minimized.

@nrc

nrc Jul 5, 2016

Member

Ok, that makes sense for motivation. I wonder if we can do better than = though.

@nrc

nrc Jul 5, 2016

Member

Ok, that makes sense for motivation. I wonder if we can do better than = though.

+The expanded error message effectively becomes a template. The text of the template is the educational text that is explaining the message more more detail. The template is then populated using the source lines, labels, and spans from the same compiler message that's printed in the default mode. This lets the message writer call out each label or span as appropriate in the expanded text.
+
+It's possible to also add additional labels that aren't necessarily shown in the default error mode but would be available in the expanded error format. This gives the explain text writer maximal flexibility without impacting the readability of the default message. I'm currently prototyping an implementation of how this templating could work in practice.
+

This comment has been minimized.

@nrc

nrc Jul 4, 2016

Member

It seems to me that there are two orthogonal features here that users might want either or both of: template explanations and inline explanations. There seems to be use cases for both (for both beginning and advanced users) so it might be nice to have access to both separately. It might be that we want to only expose one option to rustc users, but that IDEs can configure things in more detail (this might just come down to ignoring or rendering parts of the JSON errors, in practice).

@nrc

nrc Jul 4, 2016

Member

It seems to me that there are two orthogonal features here that users might want either or both of: template explanations and inline explanations. There seems to be use cases for both (for both beginning and advanced users) so it might be nice to have access to both separately. It might be that we want to only expose one option to rustc users, but that IDEs can configure things in more detail (this might just come down to ignoring or rendering parts of the JSON errors, in practice).

This comment has been minimized.

@nrc

nrc Jul 4, 2016

Member

As I mentioned earlier, I think the --explain errors should be a separate RFC, but in particular it seems premature to have an RFC without the templating language or other details specified.

@nrc

nrc Jul 4, 2016

Member

As I mentioned earlier, I think the --explain errors should be a separate RFC, but in particular it seems premature to have an RFC without the templating language or other details specified.

This comment has been minimized.

@jonathandturner

jonathandturner Jul 4, 2016

Contributor

I'm not sure I follow this point. The templating language piece seems more engineer-related rather than design related. We could iterate the templating piece without impacting the user's experience.

@jonathandturner

jonathandturner Jul 4, 2016

Contributor

I'm not sure I follow this point. The templating language piece seems more engineer-related rather than design related. We could iterate the templating piece without impacting the user's experience.

This comment has been minimized.

@nrc

nrc Jul 5, 2016

Member

I guess I think of the interface we present to Rustdoc authors as a user-facing API, not just the output of Rustdoc. Therefore, there is a design question there that should be answered in an RFC.

@nrc

nrc Jul 5, 2016

Member

I guess I think of the interface we present to Rustdoc authors as a user-facing API, not just the output of Rustdoc. Therefore, there is a design question there that should be answered in an RFC.

This comment has been minimized.

@jonathandturner

jonathandturner Jul 5, 2016

Contributor

The way I'm picturing this, only compiler authors who are writing error messages will see the templates. It's not intended to be a user-facing API for users to write their own. Similar to the existing error reporting mechanism the compiler currently uses, it would just have an additional "backend" of outputting to a template.

It sounds like you might have bigger ambitions for it? If so, we should chat.

@jonathandturner

jonathandturner Jul 5, 2016

Contributor

The way I'm picturing this, only compiler authors who are writing error messages will see the templates. It's not intended to be a user-facing API for users to write their own. Similar to the existing error reporting mechanism the compiler currently uses, it would just have an additional "backend" of outputting to a template.

It sounds like you might have bigger ambitions for it? If so, we should chat.

+Be changed to notify users of this ability:
+
+```
+note: compile failed due to 2 errors. You can compile again with `--explain errors` for more information

This comment has been minimized.

@nrc

nrc Jul 4, 2016

Member

to clarify, this should only happen if in fact there is more information to show?

@nrc

nrc Jul 4, 2016

Member

to clarify, this should only happen if in fact there is more information to show?

This comment has been minimized.

@jonathandturner

jonathandturner Jul 4, 2016

Contributor

Right, with the assumption that in the fullness of time, we have --explain errors cover most, if not all, errors.

@jonathandturner

jonathandturner Jul 4, 2016

Contributor

Right, with the assumption that in the fullness of time, we have --explain errors cover most, if not all, errors.

+
+# Stabilization
+
+Currently, these new rust error format is available on nightly using the ```export RUST_NEW_ERROR_FORMAT=true``` environment variable. Ultimately, this should become the default. In order to get there, we need to ensure that the new error format is indeed an improvement over the existing format in practice.

This comment has been minimized.

@nrc

nrc Jul 4, 2016

Member

nit grammar: "these ... is"

@nrc

nrc Jul 4, 2016

Member

nit grammar: "these ... is"

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jul 4, 2016

Contributor

@nrc

re:lack of experience with the templated format, are you specifically referring to the style of the text? In this RFC, we introduce only using the user's code rather than writing our own examples. We already have a fair bit of experience writing --explain text. It's true, though, that we haven't implemented this version, so I think it'd be natural to also keep it behind a flag for a cycle, like @alexcrichton suggested. I can see it maturing at a different rate than the new default errors, so we may decide one or the other needs longer bake time and opting to stabilize one first then the other.

You're right, though, it will need some iteration on the --explain errors side style-wise to make sure we're striking the right tone.

Contributor

jonathandturner commented Jul 4, 2016

@nrc

re:lack of experience with the templated format, are you specifically referring to the style of the text? In this RFC, we introduce only using the user's code rather than writing our own examples. We already have a fair bit of experience writing --explain text. It's true, though, that we haven't implemented this version, so I think it'd be natural to also keep it behind a flag for a cycle, like @alexcrichton suggested. I can see it maturing at a different rate than the new default errors, so we may decide one or the other needs longer bake time and opting to stabilize one first then the other.

You're right, though, it will need some iteration on the --explain errors side style-wise to make sure we're striking the right tone.

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Jul 5, 2016

Member

I was referring to the whole thing of templated explains. AIUI, we haven't implemented any version, or have I missed something? I thought the one cycle behind a flag was with the latest version of the extended errors, rather than extended explain, which presumably would need to be behind a flag or something until it stabilised (for some definition).

The tone seems like something that can be evolved separately from the technical components, and it feels like the next RFC will deal with that?

Member

nrc commented Jul 5, 2016

I was referring to the whole thing of templated explains. AIUI, we haven't implemented any version, or have I missed something? I thought the one cycle behind a flag was with the latest version of the extended errors, rather than extended explain, which presumably would need to be behind a flag or something until it stabilised (for some definition).

The tone seems like something that can be evolved separately from the technical components, and it feels like the next RFC will deal with that?

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jul 5, 2016

Contributor

@nrc - right, I'm just pointing out that we went a little out of order with the revised default errors in that we had it behind a flag before the RFC rather than the other way around. :) Yeah, the expanded ones can be behind a flag.

And yes, there will be a follow-up RFC on the tone. I mention it in this RFC in the last line of the summary.

Contributor

jonathandturner commented Jul 5, 2016

@nrc - right, I'm just pointing out that we went a little out of order with the revised default errors in that we had it behind a flag before the RFC rather than the other way around. :) Yeah, the expanded ones can be behind a flag.

And yes, there will be a follow-up RFC on the tone. I mention it in this RFC in the last line of the summary.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 5, 2016

Member

🔔 This RFC is now entering its final comment period 🔔


My own personal opinion is that I'm super excited to see this in the compiler and the new error format is great. Having any functionality behind a flag for at least a cycle makes me comfortable in terms of stability, and this is also an area where the specifics I at least believe are relatively loose as tools would primarily desire a JSON-like interface rather than parse the current format (which is in the works).

Member

alexcrichton commented Jul 5, 2016

🔔 This RFC is now entering its final comment period 🔔


My own personal opinion is that I'm super excited to see this in the compiler and the new error format is great. Having any functionality behind a flag for at least a cycle makes me comfortable in terms of stability, and this is also an area where the specifics I at least believe are relatively loose as tools would primarily desire a JSON-like interface rather than parse the current format (which is in the works).

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jul 5, 2016

Contributor

Just to follow-up here, since nrc and I were chatting a bit offline.

Basically, because of the different levels of maturity of the default and the extended errors, each will be behind a separate flag. Default will align with this rfc, stay behind flag for a cycle, then move to being on by default. Extended errors will finish experimentation, get a follow-up rfc with implementation details, and this will kick off its final cycle in moving out from under flag.

Contributor

jonathandturner commented Jul 5, 2016

Just to follow-up here, since nrc and I were chatting a bit offline.

Basically, because of the different levels of maturity of the default and the extended errors, each will be behind a separate flag. Default will align with this rfc, stay behind flag for a cycle, then move to being on by default. Extended errors will finish experimentation, get a follow-up rfc with implementation details, and this will kick off its final cycle in moving out from under flag.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 6, 2016

Member

@jonathandturner sounds good to me, could you ensure that the text of the RFC reflects that as well?

Member

alexcrichton commented Jul 6, 2016

@jonathandturner sounds good to me, could you ensure that the text of the RFC reflects that as well?

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jul 6, 2016

Contributor

@alexcrichton - updated!

Contributor

jonathandturner commented Jul 6, 2016

@alexcrichton - updated!

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 12, 2016

Contributor

I'm happy with this, though I think the --explain errors flag is awkward. If not for legacy issues I would expect this to be a single flag (--explain :p). I might prefer this to be --explain-errors. Frustrating design constraints.

I agree with @nrc that in hindsight it would have been preferable for this RFC to be just about the new error format, and not deal with --explain at all. The two features seem orthogonal.

Contributor

brson commented Jul 12, 2016

I'm happy with this, though I think the --explain errors flag is awkward. If not for legacy issues I would expect this to be a single flag (--explain :p). I might prefer this to be --explain-errors. Frustrating design constraints.

I agree with @nrc that in hindsight it would have been preferable for this RFC to be just about the new error format, and not deal with --explain at all. The two features seem orthogonal.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 12, 2016

Contributor

This RFC only specifies 1 feature name, but there are two stabilization cycles here, one for the new errors and one for the new explanations. Can a second feature be added?

Contributor

brson commented Jul 12, 2016

This RFC only specifies 1 feature name, but there are two stabilization cycles here, one for the new errors and one for the new explanations. Can a second feature be added?

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 12, 2016

Contributor

Can this RFC address the matter of editors parsing the new text? What's the story for rust-mode specifically? Is this parseable with a regex? The Drawbacks section seems to imply this, but the examples show key error information on multiple lines so it's not obvious that a single regex can parse out errors.

Contributor

brson commented Jul 12, 2016

Can this RFC address the matter of editors parsing the new text? What's the story for rust-mode specifically? Is this parseable with a regex? The Drawbacks section seems to imply this, but the examples show key error information on multiple lines so it's not obvious that a single regex can parse out errors.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jul 12, 2016

Contributor

@brson - I'd be happy to explore deprecating --explain. Since we're already going to have another RFC cycle to move the expanded errors along, perhaps we can explore replacing --explain there?

Not sure what you mean by "This RFC only specifies 1 feature name". Default errors and expanded errors are both explained here. Maybe I missed what you meant?

I've reached out to IDE authors, and they're aware of the change. Some are talking about doing JSON support, some only have minimal support for errors and don't parse, and we're working with those who are parsing the text and need to update their parser (vim specifically). I think this is okay to be offline with those authors since it'll be different for different editors. The regex details here are more specific to the regex the editors use. There are updated techniques, eg @nikomatsakis has updated his emacs install to support the newer errors, so the knowledge there is growing.

Before we turn it on by default, it'd be good to at least have editors moving to support it so that the support can be there when it's turned on in a stable release.

Contributor

jonathandturner commented Jul 12, 2016

@brson - I'd be happy to explore deprecating --explain. Since we're already going to have another RFC cycle to move the expanded errors along, perhaps we can explore replacing --explain there?

Not sure what you mean by "This RFC only specifies 1 feature name". Default errors and expanded errors are both explained here. Maybe I missed what you meant?

I've reached out to IDE authors, and they're aware of the change. Some are talking about doing JSON support, some only have minimal support for errors and don't parse, and we're working with those who are parsing the text and need to update their parser (vim specifically). I think this is okay to be offline with those authors since it'll be different for different editors. The regex details here are more specific to the regex the editors use. There are updated techniques, eg @nikomatsakis has updated his emacs install to support the newer errors, so the knowledge there is growing.

Before we turn it on by default, it'd be good to at least have editors moving to support it so that the support can be there when it's turned on in a stable release.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 13, 2016

Contributor

@brson - I'd be happy to explore deprecating --explain. Since we're already going to have another RFC cycle to move the expanded errors along, perhaps we can explore replacing --explain there?

Yes. Please make it an unresolved question here.

Not sure what you mean by "This RFC only specifies 1 feature name". Default errors and expanded errors are both explained here. Maybe I missed what you meant?

This line names a single feature, "default_and_expanded_errors_for_rustc". Presumably that one will apply to the new error format, and be attached to its tracking issue. What name will be attached to the tracking issue for enhanced --explain?

I've reached out to IDE authors, and they're aware of the change. Some are talking about doing JSON support, some only have minimal support for errors and don't parse, and we're working with those who are parsing the text and need to update their parser (vim specifically). I think this is okay to be offline with those authors since it'll be different for different editors. The regex details here are more specific to the regex the editors use. There are updated techniques, eg @nikomatsakis has updated his emacs install to support the newer errors, so the knowledge there is growing.

I don't think this addresses the concern that a single regex can pull out the error information from the text. In this example:

+error[E0499]: cannot borrow `foo.bar1` as mutable more than once at a time
+  --> src/test/compile-fail/borrowck/borrowck-borrow-from-owned-ptr.rs:29:22

The word 'error' is one one line, and the file name and number are on another. It's not obvious to me that this can be reliably parsed as a single regex, which I suspect (bot don't know), is a requirement for less capable editors. rust-mode is probably not the right barometer since emacs can execute arbitrary lisp to parse buffers. IDEs are not the main concern since they are powerful and can use JSON output - it's lesser editors like e.g. Kate. Unfortunately I don't have a concrete example of an editor that gets just a single regex to parse the error buffer (maybe @nrc or @vadimcn know).

Contributor

brson commented Jul 13, 2016

@brson - I'd be happy to explore deprecating --explain. Since we're already going to have another RFC cycle to move the expanded errors along, perhaps we can explore replacing --explain there?

Yes. Please make it an unresolved question here.

Not sure what you mean by "This RFC only specifies 1 feature name". Default errors and expanded errors are both explained here. Maybe I missed what you meant?

This line names a single feature, "default_and_expanded_errors_for_rustc". Presumably that one will apply to the new error format, and be attached to its tracking issue. What name will be attached to the tracking issue for enhanced --explain?

I've reached out to IDE authors, and they're aware of the change. Some are talking about doing JSON support, some only have minimal support for errors and don't parse, and we're working with those who are parsing the text and need to update their parser (vim specifically). I think this is okay to be offline with those authors since it'll be different for different editors. The regex details here are more specific to the regex the editors use. There are updated techniques, eg @nikomatsakis has updated his emacs install to support the newer errors, so the knowledge there is growing.

I don't think this addresses the concern that a single regex can pull out the error information from the text. In this example:

+error[E0499]: cannot borrow `foo.bar1` as mutable more than once at a time
+  --> src/test/compile-fail/borrowck/borrowck-borrow-from-owned-ptr.rs:29:22

The word 'error' is one one line, and the file name and number are on another. It's not obvious to me that this can be reliably parsed as a single regex, which I suspect (bot don't know), is a requirement for less capable editors. rust-mode is probably not the right barometer since emacs can execute arbitrary lisp to parse buffers. IDEs are not the main concern since they are powerful and can use JSON output - it's lesser editors like e.g. Kate. Unfortunately I don't have a concrete example of an editor that gets just a single regex to parse the error buffer (maybe @nrc or @vadimcn know).

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jul 13, 2016

Contributor

"The word 'error' is one one line, and the file name and number are on another. It's not obvious to me that this can be reliably parsed as a single regex, which I suspect (bot don't know), is a requirement for less capable editors." <- this is why we are reaching out to the authors of those editors. We're also looking at things we can do on our end, like better buffering of the error.

Contributor

jonathandturner commented Jul 13, 2016

"The word 'error' is one one line, and the file name and number are on another. It's not obvious to me that this can be reliably parsed as a single regex, which I suspect (bot don't know), is a requirement for less capable editors." <- this is why we are reaching out to the authors of those editors. We're also looking at things we can do on our end, like better buffering of the error.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jul 13, 2016

Contributor

"What name will be attached to the tracking issue for enhanced --explain?"

Does this need to be named in this RFC? I'm confused.

Contributor

jonathandturner commented Jul 13, 2016

"What name will be attached to the tracking issue for enhanced --explain?"

Does this need to be named in this RFC? I'm confused.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 14, 2016

Member

The tools team got a chance to discuss this RFC the other day, and the decision was to merge!

There were some key points brought up while discussing this that the tools team felt needed to be addressed before stabilization, but implementation on an unstable basis seemed fine. Specifically, we were thinking:

  • Editors - before stabilizing, the new errors need to be proven to be parseable in a number of editors. For example we should have a command-line editor like vim/emacs working but we should also have a higher level IDE like IntelliJ working. Note that we're not requiring that every editor under the sun is up to date, just that the basics are proven out and no showstoppers arise.
  • --explain - a roughly separate portion of this RFC, we're going to consider it separately for stability from the main error format. That is, we think the new error format will get turned on by default before the --explain changes are available in a stable compiler. This will likely also require a further RFC depending on the extent of the changes.

In the meantime, we'll continue to have an opt-in to using the new error format (currently an environment variable) which will allow users to test out the errors, editors to start to catch up, etc.

Thanks again for all the discussion on this RFC everyone, and thanks @jonathandturner for pushing on this! Getting lots of people happy with a stylistic decision is no small feat!

Member

alexcrichton commented Jul 14, 2016

The tools team got a chance to discuss this RFC the other day, and the decision was to merge!

There were some key points brought up while discussing this that the tools team felt needed to be addressed before stabilization, but implementation on an unstable basis seemed fine. Specifically, we were thinking:

  • Editors - before stabilizing, the new errors need to be proven to be parseable in a number of editors. For example we should have a command-line editor like vim/emacs working but we should also have a higher level IDE like IntelliJ working. Note that we're not requiring that every editor under the sun is up to date, just that the basics are proven out and no showstoppers arise.
  • --explain - a roughly separate portion of this RFC, we're going to consider it separately for stability from the main error format. That is, we think the new error format will get turned on by default before the --explain changes are available in a stable compiler. This will likely also require a further RFC depending on the extent of the changes.

In the meantime, we'll continue to have an opt-in to using the new error format (currently an environment variable) which will allow users to test out the errors, editors to start to catch up, etc.

Thanks again for all the discussion on this RFC everyone, and thanks @jonathandturner for pushing on this! Getting lots of people happy with a stylistic decision is no small feat!

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 14, 2016

Member

Tracking issue for default errors: rust-lang/rust#34826
Tracking issue for --explain: rust-lang/rust#34827

Oh and one last point --

Does this need to be named in this RFC? I'm confused.

Ah as part of --explain we don't really have a feature name like we do for libraries, so I think it's fine to just create this on the fly like we do with many others

Member

alexcrichton commented Jul 14, 2016

Tracking issue for default errors: rust-lang/rust#34826
Tracking issue for --explain: rust-lang/rust#34827

Oh and one last point --

Does this need to be named in this RFC? I'm confused.

Ah as part of --explain we don't really have a feature name like we do for libraries, so I think it's fine to just create this on the fly like we do with many others

@alexcrichton alexcrichton merged commit fc6499c into rust-lang:master Jul 14, 2016

@jonathandturner jonathandturner referenced this pull request in rust-lang/rust Aug 5, 2016

Merged

Turn on new errors and json mode #35401

bors added a commit to rust-lang/rust that referenced this pull request Aug 9, 2016

Auto merge of #35401 - jonathandturner:enable_json_and_new_errors, r=…
…nikomatsakis

Turn on new errors and json mode

This PR is a big-switch, but on a well-worn path:

* Turns on new errors by default (and removes old skool)
* Moves json output from behind a flag

The RFC for new errors [landed](rust-lang/rfcs#1644) and as part of that we wanted some bake time.  It's now had a few weeks + all the time leading up to the RFC of people banging on it.  We've also had [editors updating to the new format](saviorisdead/RustyCode#159) and expect more to follow.

We also have an [issue on old skool](#35330) that needs to be fixed as more errors are switched to the new style, but it seems silly to fix old skool errors when we fully intend to throw the switch in the near future.

This makes it lean towards "why not just throw the switch now, rather than waiting a couple more weeks?"  I only know of vim that wanted to try to parse the new format but were not sure how, and I think we can reach out to them and work out something in the 8 weeks before this would appear in a stable release.

We've [hashed out](#35330) stabilizing JSON output, and it seems like people are relatively happy making what we have v1 and then likely adding to it in the future.  The idea is that we'd maintain backward compatibility and just add new fields as needed.  We'll also work on a separate output format that'd be better suited for interactive tools like IDES (since JSON message can get a little long depending on the error).

This PR stabilizes JSON mode, allowing its use without `-Z unstable-options`

Combined, this gives editors two ways to support errors going forward: parsing the new error format or using the JSON mode.  By moving JSON to stable, we can also add support to Cargo, which plugin authors tell us does help simplify their support story.

r? @nikomatsakis
cc @rust-lang/tools

bors added a commit to rust-lang/rust that referenced this pull request Aug 9, 2016

Auto merge of #35401 - jonathandturner:enable_json_and_new_errors, r=…
…jonathandturner

Turn on new errors and json mode

This PR is a big-switch, but on a well-worn path:

* Turns on new errors by default (and removes old skool)
* Moves json output from behind a flag

The RFC for new errors [landed](rust-lang/rfcs#1644) and as part of that we wanted some bake time.  It's now had a few weeks + all the time leading up to the RFC of people banging on it.  We've also had [editors updating to the new format](saviorisdead/RustyCode#159) and expect more to follow.

We also have an [issue on old skool](#35330) that needs to be fixed as more errors are switched to the new style, but it seems silly to fix old skool errors when we fully intend to throw the switch in the near future.

This makes it lean towards "why not just throw the switch now, rather than waiting a couple more weeks?"  I only know of vim that wanted to try to parse the new format but were not sure how, and I think we can reach out to them and work out something in the 8 weeks before this would appear in a stable release.

We've [hashed out](#35330) stabilizing JSON output, and it seems like people are relatively happy making what we have v1 and then likely adding to it in the future.  The idea is that we'd maintain backward compatibility and just add new fields as needed.  We'll also work on a separate output format that'd be better suited for interactive tools like IDES (since JSON message can get a little long depending on the error).

This PR stabilizes JSON mode, allowing its use without `-Z unstable-options`

Combined, this gives editors two ways to support errors going forward: parsing the new error format or using the JSON mode.  By moving JSON to stable, we can also add support to Cargo, which plugin authors tell us does help simplify their support story.

r? @nikomatsakis
cc @rust-lang/tools

Closes #34826

@chriskrycho chriskrycho referenced this pull request in rust-lang/rust Dec 31, 2016

Closed

Document all features in the reference #38643

0 of 17 tasks complete

@chriskrycho chriskrycho referenced this pull request in rust-lang-nursery/reference Mar 11, 2017

Closed

Document all features #9

18 of 48 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment