Editor compatibility and the new error format

I think you do really want atomic messages anyway, so parallel rustc invocations don't interleave their output badly. (Hopefully one's code isn't spitting errors all over the place, but it happens.)

Hmm. I hadn't thought about the interaction with cargo. @alexcrichton confirms that when cargo runs rustc in parallel it just spits stdout/stderr directly to the console.

Apparently there is an open issue here:

So, I am wondering more and more about the buffering question. I donā€™t think it changes the fundamental calculus, but it does further shift the balance. In particular, if we modify rustc to avoid flushing in the middle of errors ā€“ or, at minimum, to flush only at particular points, such as after the --> ā€“ then this means that customizable editors can likely use multi-line regular expressions with some reliability.

This is sort of a hypothesis. The datapoints I have are based purely on emacs. There, I found that multi-line regex worked perfectly if I ran the compiler like rustc foo.rs >& ~/tmp/foo; cat ~/tmp/foo, but otherwise they workedā€¦unreliably. Some runs they matched, some runs they did not. When I dug into the code, I found that each time emacs got some text from the input stream, it would check if that text represented a complete line. If so, it would run the regex on the text, but never run it again. If it did not represent a complete line, it would buffer more. (More or less.) So this basically fits the hypothesis then. I imagine other editors will use similar logic, because itā€™s kind of hard to know just when you should ā€œre-runā€ the regex across text when new data arrives (but maybe they use some more sophisticated scheme).

So roughly how I see it now is this. Here is the set of use cases:

  1. Run from the command line.
  2. Run from the command line and pipe the output through less or into a file.
  3. Use from an editor like emacs that displays the raw compiler output but ā€œhyperlinksā€ file names.
  4. Use from an editor that completely digests the input and shows it ā€œinlineā€.
  5. Use from an unconfigured editor or tool with some default regex.

I think that 2, 3, and 5 are somewhat in tension. If we make the default be to use a ā€œtraditionalā€ output format when not writing to a tty, that disadvantages 2 and 3, because that traditional format is less readable (by definition, else we should just use it all the time). However, case 3 can be recovered if we have an environment variable, since then emacs (or whatever) can set the environment variable globally and always request ā€œnew-styleā€ output. Case 2 is still disadvantaged unless the user knows to set that variable globally; otherwise there will just be subtle differences.

Itā€™s unclear what Case 4 wants, but I guess it wants to be able to request either traditional or json output, depending on how good the output is. Traditional output would make it easier to grep around, and since you are re-display the errors, you donā€™t care if they are less readable. JSON gives you the full details, which is best of all, but itā€™s kind of unstable (something we should start a distinct thread about).

This is obviously not a proposal. I just want to kind of write out the canonical description of space and tradeoffs that I see. (Basically a refined version of my previous attempt.)

1 Like

While I can see a TTY check being used for something like colors or adjusting to the terminal width, I would find it very surprising if the output text itself changed as a result of redirection to a file. Iā€™d like to see the new format always used by default, with a flag or environment variable to handle case 5.

1 Like

Co-maintainer of Flycheck (an Emacs plugin) here :slight_smile: Thanks for announcing the change! I think weā€™ll have to update our syntax checker definition to accommodate it; a regexp description of the new format would be very useful. Alternatively, it would be really nice if rustc/cargo gained the ability to report errors in a more structured format (JSON, or checkstyle, or something that we could parse more reliably than through regexps).

Thanks for all the hard work! The new errors look very nice.

@cpitclaudel rustc already can output JSON: Do you have a tool which parses error messages?

1 Like

Note though that the current JSON output is unstable and expected to change. I have been talking with @nrc and @jntrnr on this topic: I expect weā€™ll introduce some kind of RFC, or least a discussion thread for now, detailing out plans. That said, I think that mostly weā€™ll be augmenting the current output with some more information (and maybe making a few minor changes here and there) but it will be and large stay the same.

And speaking of stabilizing the json formatā€¦ I finally got around to starting a thread about that here: Stabilizing json compiler message output

Recently Iā€™ve been attempting to add support for this new format in the rust.vim plugin. Mostly this has been successful with vimā€™s multi-line errorformat support. However, thereā€™s one problem I canā€™t think of a good solution to.

It seems that in this new format, thereā€™s no syntactic distinction between ā€œsource relatedā€ errors and ā€œmetaā€ errors. For instance, the error list now always contains error: aborting due to previous error or some variation thereof. The only difference between that and other errors is itā€™s not followed by a line with source file/line information, and thereā€™s no way to ā€œback outā€ the error since itā€™s already been matched by that point.

I can try to hard code detections for these meta-messages to filter them out, but that feels brittle, since Iā€™ll certainly miss some, or accidentally match another error. Some way of making error messages that arenā€™t associated with a source code location look different would be ideal.

I think the only meta messages that comes to mind is that very one, the ā€œerror: aborting due toā€¦ā€

We had talked about updating that after the extended error messages lands, so it will be brittle in the sense you may have to look for a couple of things it could be.

Actually, it should also be last in a set of errors. So once you see one error, you can look for the meta message to end cap the set of errors.

Thereā€™s another example. If you have no main() function in a binary crate, you get the following output:

error: main function not found
error: aborting due to previous error

The new error format has made my edit/compile/test cycle more difficult because it does not work with vim.

Please put back the ability to control how the error format works. Example: export RUST_NEW_ERROR_FORMAT=false

At least until the vim folks are able to provide a new version that works with the new format. (also, +1 to enhance the new error format so it is not ambiguous wrt source/meta)

1 Like

The new error format has made my edit/compile/test cycle more difficult because it does not work with vim.

I have been using @jpernst's PR branch (corresponding PR) which supports the new format pretty well. It could probably use more eyes on it too.

Thanks - but it doesnā€™t work for me:

  • compile from vim
  • errors are displayed
  • vim should place me at the file:line of the first error - but it creates a new empty window and places me there instead.

Iā€™ll try to work with the rust-vim folks to try to get this resolved. Still, it would be nice if there was an easy way to enable/disable the feature. Given the choice I would much prefer solid vim integration over better error messages.

I tried to reach out to the plugin authors, but in case I missed a fewā€¦

Just sending out a friendly reminder that weā€™re 17 days away from Rust 1.12, which is the first with the new error format (and removes support for the old error format). It also standardizes the JSON output format, as an alternative to trying to parse the new format.

I just wanted to mention that Iā€™ve been locked on the 8/1 nightly to keep vimā€™s error parsing plugins working. I wonā€™t be updating my stable to 1.12 either until the fixes to rust.vim land (there is an outstanding PR). rust.vim is a rust-lang project, I think it would have been nicer not to land this change by default until all the rust-lang managed editor plugins were able to support it.

For me & probably for some other users this is like experiencing a breaking language change. I canā€™t get any new features (including this awesome error format) until rust.vim is updated, & I canā€™t meaningfully contribute to hastening that because I donā€™t have the domain knowledge to get that PR ready to merge.

2 Likes

I havenā€™t had the chance to try out the rust.vim PR, I will soon though.

Hi,

new error format also broke RustDT - as a result Iā€™ll have to delay adoption of Rust 1.12.x until RustDT comes up with an updated parser as error/message navigation is one of the most important features of the IDE.

I have posted an issue to the RustDT author as well.

Such a potentially workflow-breaking decision (not running old/new error messages for a few version, with an env var switch) should have been taken a bit less lightly, IMHO.

Thereā€™s a thread about this and the json error format: https://github.com/RustDT/RustDT/issues/130

It seemed like they got it working, but I havenā€™t tried it.

1 Like