Flycheck: Support new Rust error format

[futile]

The rust compiler is switching to a new error format, see https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html. Flycheck currently only supports the old format, which is already not used anymore in rust's nightly builds.

Instead of updating to this new format, the rust compiler can also output errors as json (rustc --error-format=json), which might also be an option. This would also have the advantage of supporting both newer and older versions of the compiler. The json-error format seems to be pretty stable at this point, at least that's the story mentioned here: https://github.com/rust-lang/rust/pull/35401.

Actual discussion on the json-format: https://internals.rust-lang.org/t/stabilizing-json-compiler-message-output/3691

[fmdkdd]

Thanks for the heads up. I was aware that we would need to update flycheck to the new error format, but was waiting for it to stabilize.

As I understand, the new error format is now the default in nightly, but won't land in stable before 8 weeks. But in the meantime, flycheck won't work with nightly, and then beta.

As you suggest, the JSON output seems like the best way forward. But if the JSON format is not the same in stable and nightly, we will have to support both until the current one phases out (again, 8 weeks).

I can take a look over the week-end to see if we can support the new format without too much hassle.

[josephDunne]

+1 As I only use Nightly rust so it sucks to loose flycheck support

[cpitclaudel]

Hi all,

Just to clarify: there's no format that will work with all these versions, right? If there is, I think it would be best to wait for the JSON format to land, and then move to that. Otherwise, JSON indeed seems like the right way to go right now.

[fmdkdd]

@cpitclaudel From what I can gather, the JSON format is the same in stable and in nightly. I've just tested it on a couple of errors, and it certainly looks the same. What has changed is that it is now a stable option in nightly, while in stable and beta you would have to pass the extra -Z unstable-options argument in order to get the JSON output.

So actually, switching to the JSON output would mean keeping a single error parser for all three versions (stable/beta/nightly). We just have to pass the extra argument when facing rustc < 1.12, and drop it for >= 1.12. When 1.12 is stable, we can just get rid of this check in the code.

Otherwise, as the new error format is now the default in nightly, flycheck won't work for rust nightly users.

Any tips on parsing the JSON for flycheck? I saw that the tslint checker already parses JSON, and I was going to base the code on that.

[cpitclaudel]

The the JSON parser is a very good way to go; thanks very much for clarifying (plus, we generally like structured error formats much better).

Can we pass the -Z unstable-options for all versions, or will the newer rustc choke on it? (or are there other downsides to passing it?) If not, then we'd have no version-specific code, which would be nice.

Re JSON parsing: tslint should be a good example to base your self on. Thanks much!

[steveklabnik]

Hi all!

I was asked on IRC about some stuff, so let me fill this in:

Historically, we have allowed every version of the compiler to specify -Z unstable-options, and allow you to opt into unstable features. This was really an oversight, lost in the "zomg 1.0" rush. So, finally, we decided to fix this: the intention was that on stable, -Z unstable-options would cause a hard error, and on nightly, it would work. So https://github.com/rust-lang/rust/pull/31793 was implemented, which grandfathered in existing -Z unstable-options flags, allowing them to work on stable, but with a warning, but new options follow the "real" behavior. At some point, the intention is to remove the grandfathering, making any invocation of -Z unstable-options an issue. You can see this today:

$ rustup run stable rustc --error-format=json
error: the `-Z unstable-options` flag must also be passed to enable the flag `error-format`
$ rustup run stable rustc --error-format=json -Z unstable-options
warning: the option `Z` is unstable and should only be used on the nightly compiler, but it is currently accepted for backwards compatibility; this will soon change, see issue #31847 for more details
warning: the option `error-format` is unstable and should only be used on the nightly compiler, but it is currently accepted for backwards compatibility; this will soon change, see issue #31847 for more details
{"message":"no input filename given","code":null,"level":"error","spans":[],"children":[],"rendered":null}
$ rustup run nightly rustc --error-format=json -Z unstable-options
{"message":"no input filename given","code":null,"level":"error","spans":[],"children":[],"rendered":null}

So, what does this mean? Well, the real question is, when does this hard error get turned on, and when does --error-format=json become stable. If it becomes a hard error before the format goes stable, then flycheck will lose support for stable Rust. This seems bad. I would weigh in on https://github.com/rust-lang/rust/issues/31847 to make sure that this doesn't happen.

If the format becomes stable, then you will no longer need to pass in -Z unstable options on that version of Rust. But, you _will_ need it on all the previous versions of Rust you want to support, because, as you can see from that first line, it will error without it today, but it will error with it once we flip that switch.

Does that make sense?

[fmdkdd]

@steveklabnik Thank you for the enlightening background on this.

So if I understand correctly, it's a race condition between making UnstableButNotReally options hard errors and making --error-format a stable option.

But here's the bit I don't quite understand: rust-lang/rust#35401 merged into master 2 days ago, making --error-format a stable option. Meanwhile, the discussion over at rust-lang/rust#31847 is still happening, meaning that hard errors have not yet been turned on. Even if hard errors get turned on today, --error-format would not be affected, since it's not an UnstableButNotReally option anymore.

It seems to me the race has already been won by --error-format, and this could change only if rust-lang/rust#35401 is reverted (which, looking at the discussion in rust-lang/rust#35401, seems unlikely). Or am I missing something?

In any case, it seems a good idea to weigh in in the discussion as you said, if only for our use of -Z --no-trans.

@cpitclaudel It seems that passing -Z unstable-options in nightly is harmless. So we might not need a version check. But, maybe the mere presence of -Z unstable-option on stable rust will trigger an error in the future, so we would have to revisit the code when it does.

While you are here @steveklabnik, when (if ever) do rust stable versions become unsupported? I think the JSON output is only for rustc >= 1.7, so if we switch to it in flycheck, it would not work anymore for anyone using a rustc prior to 1.7. The dual question is: are there any downsides to upgrading to the latest stable? Breaking changes?

[lunaryorn]

I'd not spent too much time on backwards compatibility considerations. If we only support Rust 1.7 or newer so be it. It won't do much harm I guess, most folks seem to be using recent releases or nightly anyway.