Error message update RFC and IDE impact

[sophiajt]

Hey all,

Sorry for using an issue as a message box, but I wasn't sure who to contact.

I/we are currently working on an RFC that will change up the compiler error output a bit: rust-lang/rfcs#1644 This may have some IDE impacts, if the plugin is doing a match against the output.

We've also been talking about standardizing a JSON output for the compiler so that IDEs can get more information that way.

Would love to get your feedback on what impact it has on the vim plugin.

[chris-morgan]

An issue is the right way of handling it! (BTW, there’s the @rust-lang/rust-vim team so you can call us (OK, only me and brson at present) in on an issue in another repository if you want.)

Vim’s compiler error handling is text-based; see the errorformat docs for info. It also supports only one line of message per error, which probably means that we’re not going to be able to transmit everything. It will necessarily be a slightly more limited thing. For multi-line messages you could craft multiple error lines, each with a part of the full message, but that’s not the nicest thing (though it may be helpful) and it does mess up the error counts.

If the compiler were to emit exclusively JSON, we’d need a way of parsing it. For 'makeprg', I don’t believe there’s a way of processing the output of the program before errorformats has at it. That means writing a program wrapping rustc/cargo and turning its JSON into something simple to parse. (That means either making a slow mess of shell/batch + vimscripts for JSON parsing, or writing something in Rust, which is guaranteed to be available.) I’d certainly prefer it if rustc had two forms of output for tooling: JSON with all the info, and plain text single-line-per-message mostly as it used to be (e.g. file.rs:1:1: error: message [E0000], but making sure it’s only one line per message) form.

I’ve ignored syntastic in this; it’s going to be equal to or more powerful than errorformat/makeprg. (There may be a way of hooking a decoding function into it that isn’t string-based; I don’t know.)

[nikomatsakis]

@chris-morgan

It also supports only one line of message per error, which probably means that we’re not going to be able to transmit everything.

I'm not quite sure what this means -- there is a whole section on matching multi-line error messages?

[chris-morgan]

@nikomatsakis I mean that it supports only one line of descriptive text per error message. So if you have this:

file:line:col error: such and such
    and also so and so

You can’t get the likes of “such and such\nand also so and so” as the message of an error.

Multi-line error message support in Vim means that you can have file, line, column, type and message on different lines.

[sophiajt]

Ah, that's good. The current plan isn't to span multiple lines with the error description, but rather to put the file location on the separate line.

[sophiajt]

Just a heads up that we're currently talking about turning on the new errors: rust-lang/rust#35401

If there are issues that are holding up this plugin, please weigh in and let us know (or respond here). If it's accepted this week, there's still time before it's available in a stable release to update the plugin. We want as best as possible for the transition to go smoothly, so please let us know.

[sophiajt]

Just wanted to check in to see how progress was on support. We're 17 days away from the release of 1.12, which will have the new errors on and no more support for the old error format. It also has a standardized JSON output format.

There's been some talk about the single-line format, though no work has made it into the compiler for that at this time (which means no support for 1.12, as it's already locked in).

[da-x]

Discussion ended awhile ago, closing.