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:
- Run from the command line.
- Run from the command line and pipe the output through less or into a file.
- Use from an editor like emacs that displays the raw compiler output but āhyperlinksā file names.
- Use from an editor that completely digests the input and shows it āinlineā.
- 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 
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 errorThe 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
Iāve built RustDT from their Master branch at it seems to be picking up the Json errors - itās a bit more work than I expected but at least I could hammer it into obedience.
I guess panic over but edges are bleeding profusely
If it helps:
- build RustDT from source (Iām hitting Master/HEAD)
cd /your/projects/dir
git clone https://github.com/RustDT/RustDT.git
cd RustDT/
mvn clean package
-
In Eclipse: Help/Install new software -> Addā¦ Name: RustDT (Local) Location:
file:/your/projects/dir/RustDT/bin-maven/features.repository/repository/Select RustDT Project, Next> continue install until RustDT is updated, restart IDE when asked. -
In Eclipse, Project Explorer Right click on your project -> Rust Build Targets -> Select Build, replace default value with
${CARGO_TOOL_PATH} test --no-run -- --error-format=json-> OK
Build project now should produce Json errors, will be picked up in the Problems view.
1 Like