Add --message-format flag. #3000

Merged
merged 6 commits into from Oct 6, 2016

Conversation

Projects
None yet
9 participants
@matklad
Member

matklad commented Aug 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Aug 16, 2016

r? @alexcrichton

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

r? @alexcrichton

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

@matklad

This comment has been minimized.

Show comment
Hide comment
@matklad

matklad Aug 17, 2016

Member

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

Member

matklad commented Aug 17, 2016

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 17, 2016

Member

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.

Member

alexcrichton commented Aug 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@matklad

matklad Aug 17, 2016

Member

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?

Member

matklad commented Aug 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Aug 17, 2016

Member

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.

Member

nrc commented Aug 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 18, 2016

Member

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

Member

alexcrichton commented Aug 18, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@matklad

matklad Aug 19, 2016

Member

@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?

Member

matklad commented Aug 19, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 19, 2016

Member

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

Member

alexcrichton commented Aug 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Aug 23, 2016

Contributor

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.

Contributor

brson commented Aug 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 31, 2016

Contributor

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

Contributor

bors commented Aug 31, 2016

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

@matklad

This comment has been minimized.

Show comment
Hide comment
@matklad

matklad Sep 14, 2016

Member

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.

Member

matklad commented Sep 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Sep 14, 2016

Member

@matklad sounds good to me!

Member

alexcrichton commented Sep 14, 2016

@matklad sounds good to me!

@matklad

This comment has been minimized.

Show comment
Hide comment
@matklad

matklad Sep 16, 2016

Member

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?

Member

matklad commented Sep 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kevincox

kevincox Sep 16, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@White-Oak

White-Oak Sep 16, 2016

@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 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

This comment has been minimized.

Show comment
Hide comment
@matklad

matklad Sep 16, 2016

Member

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!

Member

matklad commented Sep 16, 2016

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!

bors added a commit that referenced this pull request Sep 26, 2016

Auto merge of #3091 - matklad:move-exec-streamed, r=alexcrichton
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?

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 comment has been minimized.

@alexcrichton

alexcrichton Sep 26, 2016

Member

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

@alexcrichton

alexcrichton Sep 26, 2016

Member

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

src/cargo/ops/cargo_compile.rs
+ Json
+}
+
+impl MessageFormat {

This comment has been minimized.

@alexcrichton

alexcrichton Sep 26, 2016

Member

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

@alexcrichton

alexcrichton Sep 26, 2016

Member

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

This comment has been minimized.

@alexcrichton

alexcrichton Sep 29, 2016

Member

thoughts on this?

@alexcrichton

alexcrichton Sep 29, 2016

Member

thoughts on this?

This comment has been minimized.

@matklad

matklad Sep 29, 2016

Member

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.

@matklad

matklad Sep 29, 2016

Member

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.

src/cargo/ops/cargo_rustc/mod.rs
+ message: json::Json,
+ }
+ process_builder.exec_with_streaming(
+ &mut |line| assert!(line.is_empty()),

This comment has been minimized.

@alexcrichton

alexcrichton Sep 26, 2016

Member

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

@alexcrichton

alexcrichton Sep 26, 2016

Member

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

src/cargo/ops/cargo_rustc/mod.rs
+ let process_builder = rustc.into_process_builder();
+ try!(if json_errors {
+ #[derive(RustcEncodable)]
+ struct Message<'a> {

This comment has been minimized.

@alexcrichton

alexcrichton Sep 26, 2016

Member

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.

@alexcrichton

alexcrichton Sep 26, 2016

Member

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

This comment has been minimized.

Show comment
Hide comment
@matklad

matklad Sep 27, 2016

Member

@alexcrichton

What do you think about

what stream should be used for JSON?

Member

matklad commented Sep 27, 2016

@alexcrichton

What do you think about

what stream should be used for JSON?

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Sep 27, 2016

Member

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.

Member

alexcrichton commented Sep 27, 2016

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.

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>>,

This comment has been minimized.

@alexcrichton

alexcrichton Sep 29, 2016

Member

Perhaps Box<CargoError>?

@alexcrichton

alexcrichton Sep 29, 2016

Member

Perhaps Box<CargoError>?

@matklad

This comment has been minimized.

Show comment
Hide comment
@matklad

matklad Oct 2, 2016

Member

So I think this is basically ready.

I am still not sure about the usage of streams, so let's recap the current situation, the changes this PR brings and the hypothetical end game:

  • Currently, JSON output of cargo metadata goes to stdout. Cargo's and compiler's messages are plain text and use stderr.
  • After this PR, it would be possible to get compier's messages in JSON on the stderr. But there will be plain text Cargo messages as well.
  • In the future, we should use JSON and stderr for Cargo messages as well. This will mean that for cargo metadata there will be JSON on both streams. Also, we perhaps want to add new kinds of messaged, for example, cargo build could print the names of output artifacts. This should be just another kind of status message and go to stderr.
Member

matklad commented Oct 2, 2016

So I think this is basically ready.

I am still not sure about the usage of streams, so let's recap the current situation, the changes this PR brings and the hypothetical end game:

  • Currently, JSON output of cargo metadata goes to stdout. Cargo's and compiler's messages are plain text and use stderr.
  • After this PR, it would be possible to get compier's messages in JSON on the stderr. But there will be plain text Cargo messages as well.
  • In the future, we should use JSON and stderr for Cargo messages as well. This will mean that for cargo metadata there will be JSON on both streams. Also, we perhaps want to add new kinds of messaged, for example, cargo build could print the names of output artifacts. This should be just another kind of status message and go to stderr.
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Oct 4, 2016

Member

Ok I think the last stickler point in my mind is where this output is going. I think I agree with @kevincox from before about Cargo's JSON output should go to stdout instead of stderr. That'd cause situations like:

cargo build --message-format json > output.json

"just work"

You'd get a bunch of JSON in output.json and then you'd still get a list of human readable messages on the terminal as well. Note that'd also keep consistency with cargo metadata as well which currently outputs on stdout.

Thoughts?

(other than that though the PR looked great!)

Member

alexcrichton commented Oct 4, 2016

Ok I think the last stickler point in my mind is where this output is going. I think I agree with @kevincox from before about Cargo's JSON output should go to stdout instead of stderr. That'd cause situations like:

cargo build --message-format json > output.json

"just work"

You'd get a bunch of JSON in output.json and then you'd still get a list of human readable messages on the terminal as well. Note that'd also keep consistency with cargo metadata as well which currently outputs on stdout.

Thoughts?

(other than that though the PR looked great!)

@matklad

This comment has been minimized.

Show comment
Hide comment
@matklad

matklad Oct 4, 2016

Member

Thoughts?

I am in the stdout camp. And looks like Microsoft compilers use stdout for errors ( Microsoft/TypeScript#615 )

Previously you'd said

I don't want to rail up against the compiler and we should follow suit there.

Does this mean that you've changed your mind?

Member

matklad commented Oct 4, 2016

Thoughts?

I am in the stdout camp. And looks like Microsoft compilers use stdout for errors ( Microsoft/TypeScript#615 )

Previously you'd said

I don't want to rail up against the compiler and we should follow suit there.

Does this mean that you've changed your mind?

@White-Oak

This comment has been minimized.

Show comment
Hide comment
@White-Oak

White-Oak Oct 4, 2016

@alexcrichton this will be a little bit unconvenient for IDE and plugin developers (as we need to support both the legacy and the current version of cargo & rustc), but I guess, it's okay. However, I don't really understand why "getting human-readable output" matters, if consumers of this mode are supposed to be tools.

@matklad

And looks like Microsoft compilers use stdout for errors ( Microsoft/TypeScript#615 )

Yes, but rustc uses stderr, and its' long past 1.0 version to change this I beleive

White-Oak commented Oct 4, 2016

@alexcrichton this will be a little bit unconvenient for IDE and plugin developers (as we need to support both the legacy and the current version of cargo & rustc), but I guess, it's okay. However, I don't really understand why "getting human-readable output" matters, if consumers of this mode are supposed to be tools.

@matklad

And looks like Microsoft compilers use stdout for errors ( Microsoft/TypeScript#615 )

Yes, but rustc uses stderr, and its' long past 1.0 version to change this I beleive

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Oct 4, 2016

Member

@matklad yeah I'm somewhat coming around to it being ok if cargo/rustc are different.

@White-Oak hm yeah that's true. Wouldn't the code paths for dealing with rustc vs cargo manually though be very different anyway?

Member

alexcrichton commented Oct 4, 2016

@matklad yeah I'm somewhat coming around to it being ok if cargo/rustc are different.

@White-Oak hm yeah that's true. Wouldn't the code paths for dealing with rustc vs cargo manually though be very different anyway?

@White-Oak

This comment has been minimized.

Show comment
Hide comment
@White-Oak

White-Oak Oct 4, 2016

@alexcrichton well, it was not that different, when dealing with output before, but since here is introduced the new format (theoretically speaking, it's a wrapper of a rustc JSON format, but practically speaking, from a point of tools' view, it should be treated differently), why not change one more thing while we are at it? :)

Of course, either way is not a big deal: adding a few ifs will handle that (:
But it may be a little bit confusing in a general sense -- why does that mode (and only that one) treats output differently (by starting to output its thing to stdout)? Or, to put it the other way: why is this mode -- an exception?

But, as I said before, I'm not really for or against that -- I just hope it would be documented properly (specifying that stdout is used for output) :)

@alexcrichton well, it was not that different, when dealing with output before, but since here is introduced the new format (theoretically speaking, it's a wrapper of a rustc JSON format, but practically speaking, from a point of tools' view, it should be treated differently), why not change one more thing while we are at it? :)

Of course, either way is not a big deal: adding a few ifs will handle that (:
But it may be a little bit confusing in a general sense -- why does that mode (and only that one) treats output differently (by starting to output its thing to stdout)? Or, to put it the other way: why is this mode -- an exception?

But, as I said before, I'm not really for or against that -- I just hope it would be documented properly (specifying that stdout is used for output) :)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Oct 4, 2016

Member

@White-Oak ah I was just thinking that it makes sense for all machine-readable output to go to stdout where explicitly human readable messages to go stderr (e.g. what Cargo prints today). I don't think a lot of thought was put into this on the compiler side, so following precdent there may not always be quite right?

Member

alexcrichton commented Oct 4, 2016

@White-Oak ah I was just thinking that it makes sense for all machine-readable output to go to stdout where explicitly human readable messages to go stderr (e.g. what Cargo prints today). I don't think a lot of thought was put into this on the compiler side, so following precdent there may not always be quite right?

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Oct 5, 2016

Member

Ok, discussed during tools triage yesterday and the conclusion was that we should stick the JSON on stdout. @matklad want to update and I'll r+?

Member

alexcrichton commented Oct 5, 2016

Ok, discussed during tools triage yesterday and the conclusion was that we should stick the JSON on stdout. @matklad want to update and I'll r+?

@matklad

This comment has been minimized.

Show comment
Hide comment
@matklad

matklad Oct 5, 2016

Member

Yep, will switch to stdout later today.

Member

matklad commented Oct 5, 2016

Yep, will switch to stdout later today.

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

This comment has been minimized.

@matklad

matklad Oct 5, 2016

Member

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

@matklad

matklad Oct 5, 2016

Member

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

This comment has been minimized.

@alexcrichton

alexcrichton Oct 5, 2016

Member

Yeah this is fine!

@alexcrichton

alexcrichton Oct 5, 2016

Member

Yeah this is fine!

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
Member

alexcrichton commented Oct 6, 2016

@bors: r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Oct 6, 2016

Contributor

📌 Commit b9ec2b1 has been approved by alexcrichton

Contributor

bors commented Oct 6, 2016

📌 Commit b9ec2b1 has been approved by alexcrichton

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Oct 6, 2016

Contributor

⌛️ Testing commit b9ec2b1 with merge 964afba...

Contributor

bors commented Oct 6, 2016

⌛️ Testing commit b9ec2b1 with merge 964afba...

bors added a commit that referenced this pull request Oct 6, 2016

Auto merge of #3000 - matklad:error-format, r=alexcrichton
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.
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Oct 6, 2016

Member

@bors: retry force clean

Member

alexcrichton commented Oct 6, 2016

@bors: retry force clean

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Oct 6, 2016

Contributor

⌛️ Testing commit b9ec2b1 with merge c9c8a6e...

Contributor

bors commented Oct 6, 2016

⌛️ Testing commit b9ec2b1 with merge c9c8a6e...

bors added a commit that referenced this pull request Oct 6, 2016

Auto merge of #3000 - matklad:error-format, r=alexcrichton
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.
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Oct 6, 2016

Member

@bors: retry force clean

Member

alexcrichton commented Oct 6, 2016

@bors: retry force clean

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Oct 6, 2016

Contributor

⌛️ Testing commit b9ec2b1 with merge 0873893...

Contributor

bors commented Oct 6, 2016

⌛️ Testing commit b9ec2b1 with merge 0873893...

bors added a commit that referenced this pull request Oct 6, 2016

Auto merge of #3000 - matklad:error-format, r=alexcrichton
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

This comment has been minimized.

Show comment
Hide comment
@bors

bors Oct 6, 2016

Contributor
Contributor

bors commented Oct 6, 2016

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

2 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
homu Test successful
Details
@jplatte

This comment has been minimized.

Show comment
Hide comment
@jplatte

jplatte Oct 10, 2016

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

jplatte commented Oct 10, 2016

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Oct 10, 2016

Member

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

Member

alexcrichton commented Oct 10, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment