Editor compatibility and the new error format

[rkjnsn]

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.

[cpitclaudel]

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.

[matklad]

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

[nikomatsakis]

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.

[jntrnr]

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

[jpernst]

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.

[jntrnr]

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.

[alygin]

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

[MarkSwanson]

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)

[ExpHP]

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.

[MarkSwanson]

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.

[jntrnr]

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.

[withoutboats]

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.

[steveklabnik]

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

[norru]

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.

[jntrnr]

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.

[norru]

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:

1. 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

2. 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.

3. 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.

[bruno_medeiros]

3. 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

You don’t need this third step. RustDT will automatically setup the RUSTFLAGS env var to add “–error-format=json”

[norru]

Yep, tried that, the RustDT built from source doesn’t need it. Cheers!

[nikomatsakis]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.