Add --message-format flag. #3000

matklad · 2016-08-16T12:53:36Z

Closes #2982

This adds a --message-format flag with values human or json-v1 to commands that may trigger compilation.

After the discussion in the issue I am no longer sure that this is a way to go:

Looks like it buys nothing compared to RUST_FLAGS approach: a flag is more useful on the command line, but from the tool point of view there should be no significant differences between a flag and an environmental variable.
Looks like we really want to wrap compiler's messages into our own json to tie them to particular compilation.

rust-highfive · 2016-08-16T12:53:47Z

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

matklad · 2016-08-17T01:03:22Z

Not sure why appveyor fails: looks like it uses an older nightly, which requires -Z unstable-options.

alexcrichton · 2016-08-17T18:16:13Z

Thanks for the PR @matklad! This looks pretty good to me in terms of plumbing.

I think this is important over RUSTFLAGS because Cargo has intrusive knowledge that this flag doesn't change the output artifact (e.g. for using previously built artifacts). Other than that though yeah it looks like it's not buying a huge amount.

cc @rust-lang/tools, what would your expectations here be? If we're emitting JSON, should Cargo emit everything as JSON (e.g. status messages as well). Additionally, should Cargo always wrap the compiler's error messages with its own JSON documents? That way we could attribute what crate's being compiled, what version, etc.

matklad · 2016-08-17T19:22:48Z

I think this is important over RUSTFLAGS because Cargo has intrusive knowledge that this flag doesn't change the output artifact (e.g. for using previously built artifacts)

Yes, I totally missed this effect, this is a huge argument in favor of custom flag.

If we're emitting JSON, should Cargo emit everything as JSON (e.g. status messages as well). Additionally, should Cargo always wrap the compiler's error messages with its own JSON documents?

Are there any tools which already require this info?

nrc · 2016-08-17T21:28:33Z

If we're emitting JSON, should Cargo emit everything as JSON (e.g. status messages as well).

I would like this as a long-term goal, but in the short-term, tools should handle the mix (to be defensive, they'll have to handle a mix in any case).

Additionally, should Cargo always wrap the compiler's error messages with its own JSON documents?

I would like this. Not sure it has to block, but it should certainly happen at some point.

alexcrichton · 2016-08-18T15:19:20Z

@matklad

Are there any tools which already require this info?

I don't think so, but it provides us a lot of flexibility where we could just send "status reports" every so often from Cargo for when something is happening.

@nrc

I would like this. Not sure it has to block, but it should certainly happen at some point.

I kind of agree, and I feel like it's best to get it out of the way sooner rather than later. @matklad would you be open to exploring this?

The final product would look similar to this where you'd basically read the output in a streaming fashion line-by-line. Each line of JSON would then be wrapped in our own, and otherwise all other output would be forwarded to the console.

matklad · 2016-08-19T08:34:20Z

@matklad would you be open to exploring this?

I would prefer to do #3003 first. Doing wrapping also requires some design work: just what exactly is the message format and how do we identify particular compilation?

alexcrichton · 2016-08-19T20:00:29Z

I would think we could start out with a simple schema like:

{
    "crate": "crate-name",
    "version": "crate-version",
    "source": "url",
    "message": { ... },
    "reason": "rustc-message"<
}

We could expand that over time, but we should always have all those pieces of information at least

brson · 2016-08-23T18:49:37Z

I agree that it would be best for cargo to wrap rustc's json. But if it's too onerous to do that now it could be designed in a way that tools can detect whether they are seeing rustc-json or cargo-json.

cc @jonathandturner another json error format being proposed.

bors · 2016-08-31T19:16:07Z

☔ The latest upstream changes (presumably #3038) made this pull request unmergeable. Please resolve the merge conflicts.

matklad · 2016-09-14T15:40:04Z

We could expand that over time, but we should always have all those pieces of information at least

@alexcrichton what do you think about including only PackageId and Target in the output? Source, version, crate name, etc can then be learned by finding the package in the cargo metadata output.

alexcrichton · 2016-09-14T21:47:54Z

@matklad sounds good to me!

matklad · 2016-09-16T01:06:59Z

And one more question: what stream should be used for JSON?

I think that it should be stdout, because it is intended for machines (see also comments by @kamalmarhubi and @kevincox on this issue).

An immediate practical benefit is that the consumers wouldn't need to filter JSON from diagnostic messages.

But rustc outputs JSON to stderr,.. perhaps this is wrong?

kevincox · 2016-09-16T07:42:42Z

I would argue that stdout is the right place. Because this becomes the output and it's intended for machines. Then you "could" put human readable warnings and errors on stderr without breaking the JSON. However in this case that's probably not very useful because the JSON output specifically includes errors and warnings.

White-Oak · 2016-09-16T08:33:05Z

@matklad I'm pretty sure rustc and cargo output to stderr, and I believe this is semantically right. Also, to 'machines' there is really no difference between reading stderr and stdout.

I am really excited for this PR, but it's a a bit sad it won't be included in the same stable version as new and JSON errors are.

matklad · 2016-09-16T08:42:07Z

However in this case that's probably not very useful because the JSON output specifically includes errors and warnings.

There are diagnostic messages from the Cargo itself, which are not JSON at the moment.

but it's a a bit sad it won't be included in the same stable version as new and JSON errors are.

Yep, Cargo naturally lags behind rustc for some features because they have to be implemented in the compiler first. However you could use nightly Cargo with stable rustc!

Move stream_output to ProcessBuilder Make `stream_output` method more reusable (I intend to use it in #3000). Unrelated question: what is that `ExecEngine` thing? Looks like it does nothing at the moment and can be removed.

alexcrichton

Thanks @matklad! Could you also add some documentation on this feature as well?

Also cc @rust-lang/tools and @jonathandturner, JSON errors plumbed through Cargo along with future extensibility so we can add more JSON to the output stream of Cargo.

Right now this is exposed through cargo build --message-format json-v1. The v1 is in theory so we can change the JSON format later, but the compiler doesn't have this, so maybe it's just wishful thinking?

alexcrichton · 2016-09-26T18:08:46Z

src/cargo/ops/cargo_rustc/mod.rs

+                &mut |line| assert!(line.is_empty()),
+                &mut |line| {
+                    let rustc_message = json::Json::from_str(line).unwrap_or_else(|_| {
+                        panic!("Compiler produced invalid json: `{}`", line)


This should probably get translated to a normal error instead of a panic

alexcrichton · 2016-09-26T18:09:58Z

src/cargo/ops/cargo_compile.rs

+    Json
+}
+
+impl MessageFormat {


You can probably get away from directly implementing rustc_serialize::Decodable here as that'll thread all the way through docopt I think.

thoughts on this?

Yep, I'll do this when I have time (soonish). I think I'll leave json instead of json-v1. v1 was intended for "let's output compiler messages as is, and wrap them later", but we are already do the streaming.

alexcrichton · 2016-09-26T18:10:48Z

src/cargo/ops/cargo_rustc/mod.rs

+                message: json::Json,
+            }
+            process_builder.exec_with_streaming(
+                &mut |line| assert!(line.is_empty()),


(same with below, this'll want to be a normal error not a panic)

alexcrichton · 2016-09-26T18:12:05Z

src/cargo/ops/cargo_rustc/mod.rs

+        let process_builder = rustc.into_process_builder();
+        try!(if json_errors {
+            #[derive(RustcEncodable)]
+            struct Message<'a> {


Perhaps this could be defined in a more central location? This'd in theory I guess actually be some sort of enum for the messages that get emitted, and all of them have a reason.

matklad · 2016-09-27T11:50:59Z

@alexcrichton

What do you think about

what stream should be used for JSON?

alexcrichton · 2016-09-27T22:11:38Z

I personally feel like stdout is the best option here, but I don't want to rail up against the compiler and we should follow suit there.

alexcrichton · 2016-09-29T17:20:04Z

src/cargo/util/errors.rs

@@ -110,13 +110,13 @@ pub struct ProcessError {
    pub desc: String,
    pub exit: Option<ExitStatus>,
    pub output: Option<Output>,
-    cause: Option<io::Error>,
+    cause: Option<Box<Error + Send>>,


Perhaps Box<CargoError>?

matklad · 2016-10-05T18:32:18Z

src/cargo/util/machine_message.rs

+
+    pub fn emit(self) {
+        let json = json::encode(&self).unwrap();
+        println!("{}", json);


@alexcrichton is this the right way to print JSON to stdout? There is no error reporting, and it bypasses config.shell altogether, but I think both of these are OK: we don't use colors, so we don't need shell, println does necessary synchronization, and it is probably OK to panic if we fail to write to stdout.

Yeah this is fine!

alexcrichton · 2016-10-06T16:56:03Z

@bors: r+

bors · 2016-10-06T16:56:04Z

📌 Commit b9ec2b1 has been approved by alexcrichton

bors · 2016-10-06T18:04:18Z

⌛ Testing commit b9ec2b1 with merge 964afba...

alexcrichton · 2016-10-06T18:17:24Z

@bors: retry force clean

bors · 2016-10-06T18:21:48Z

⌛ Testing commit b9ec2b1 with merge c9c8a6e...

alexcrichton · 2016-10-06T21:03:02Z

@bors: retry force clean

bors · 2016-10-06T21:03:23Z

⌛ Testing commit b9ec2b1 with merge 0873893...

Add --message-format flag. Closes #2982 This adds a `--message-format` flag with values `human` or `json-v1` to commands that may trigger compilation. After the discussion in the issue I am no longer sure that this is a way to go: * Looks like it buys nothing compared to `RUST_FLAGS` approach: a flag is more useful on the command line, but from the tool point of view there should be no significant differences between a flag and an environmental variable. * Looks like we really want to wrap compiler's messages into our own json to tie them to particular compilation.

bors · 2016-10-06T21:52:23Z

☀️ Test successful - cargo-cross-linux, cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64
Approved by: alexcrichton
Pushing 0873893 to master...

jplatte · 2016-10-10T06:03:54Z

Is there an ETA for the next release that will include this feature?

alexcrichton · 2016-10-10T14:51:06Z

@jplatte this'll be released with Rust 1.14 on 2016-12-22

rust-highfive assigned alexcrichton Aug 16, 2016

matklad force-pushed the error-format branch from 35245a9 to dc6ee7a Compare August 16, 2016 23:14

matklad force-pushed the error-format branch from dc6ee7a to c16f8b1 Compare September 14, 2016 15:07

matklad mentioned this pull request Sep 14, 2016

Move stream_output to ProcessBuilder #3091

Merged

matklad mentioned this pull request Sep 15, 2016

Changing RUSTFLAGS to use JSON errors causes whole rebuild of a project #3095

Closed

matklad force-pushed the error-format branch 2 times, most recently from 74af75d to 4537d66 Compare September 17, 2016 14:04

alexcrichton reviewed Sep 26, 2016

View reviewed changes

alexcrichton reviewed Sep 29, 2016

View reviewed changes

alexcrichton mentioned this pull request Sep 30, 2016

Don't force recompilation when setting/removing the --error-format compiler flag #3141

Closed

Add --message-format flag.

9f98208

Add some docs about JSON messages

b9ec2b1

matklad force-pushed the error-format branch from 625d16c to b9ec2b1 Compare October 5, 2016 18:26

matklad commented Oct 5, 2016

View reviewed changes

bors merged commit b9ec2b1 into rust-lang:master Oct 6, 2016

alexcrichton mentioned this pull request Oct 6, 2016

Intermingled JSON output from concurrent compilers rust-lang/rust#37011

Closed

This was referenced Oct 11, 2016

Support Cargo's Json output RustDT/RustDT#138

Closed

Can rustup be used to create a toolchain with nightly Cargo and stable rustc? rust-lang/rustup#755

Closed

Boddlnagg mentioned this pull request Oct 12, 2016

New project system & Cargo based build system PistonDevelopers/VisualRust#234

Merged

jsgf mentioned this pull request Oct 19, 2016

Export more build metadata from cargo build #3212

Closed

skywind3000 mentioned this pull request Oct 27, 2016

Output is not matched by errorformat, which is defined by :compiler command skywind3000/asyncrun.vim#16

Closed

Boddlnagg mentioned this pull request Nov 9, 2016

No supported installation of cargo.exe found PistonDevelopers/VisualRust#254

Open

White-Oak mentioned this pull request Nov 11, 2016

--message-format is released ahead of time #3282

Closed

fmdkdd mentioned this pull request Dec 12, 2016

Errors are not always output as JSON flycheck/flycheck-rust#45

Closed

matklad deleted the error-format branch December 14, 2016 15:27

dtretyakov mentioned this pull request Jan 24, 2017

Support --message-format=json option JetBrains/teamcity-rust-plugin#28

Open

alexcrichton mentioned this pull request Jun 19, 2017

compilation of rustc fails when verbose=1 in config.toml and --incremental is passed rust-lang/rust#42583

Closed

hafeoz mentioned this pull request Jan 13, 2022

Use Cargo's JSON diagnostics for suggestions rust-lang/rust-playground#767

Closed

5 tasks

Add --message-format flag. #3000

Add --message-format flag. #3000

Conversation

matklad commented Aug 16, 2016

rust-highfive commented Aug 16, 2016

matklad commented Aug 17, 2016

alexcrichton commented Aug 17, 2016

matklad commented Aug 17, 2016

nrc commented Aug 17, 2016

alexcrichton commented Aug 18, 2016

matklad commented Aug 19, 2016

alexcrichton commented Aug 19, 2016

brson commented Aug 23, 2016

bors commented Aug 31, 2016

matklad commented Sep 14, 2016

alexcrichton commented Sep 14, 2016

matklad commented Sep 16, 2016 • edited Loading

kevincox commented Sep 16, 2016

White-Oak commented Sep 16, 2016

matklad commented Sep 16, 2016

alexcrichton left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcrichton Sep 26, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

matklad commented Sep 27, 2016

alexcrichton commented Sep 27, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcrichton commented Oct 6, 2016

bors commented Oct 6, 2016

bors commented Oct 6, 2016

alexcrichton commented Oct 6, 2016

bors commented Oct 6, 2016

alexcrichton commented Oct 6, 2016

bors commented Oct 6, 2016

bors commented Oct 6, 2016

jplatte commented Oct 10, 2016

alexcrichton commented Oct 10, 2016 • edited Loading

matklad commented Sep 16, 2016 •

edited

Loading

alexcrichton Sep 26, 2016 •

edited

Loading

alexcrichton commented Oct 10, 2016 •

edited

Loading