Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
anderspapitto opened this issue Jun 10, 2017 · 7 comments
Labels
T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Comments

@anderspapitto
Copy link
Contributor

here's the relevant snippet of output, from running x.py build --stage 1 --incremental

--- stdout
incremental: 174974 nodes in dep-graph
incremental: 1330925 edges in dep-graph
incremental: 31177 nodes in reduced dep-graph
incremental: 262939 edges in serialized dep-graph
incremental: 9004 hashes in serialized dep-graph
incremental: re-using 0 out of 65 modules


Caused by:
  compiler stdout is not empty: `incremental: 174974 nodes in dep-graph`
@vadimcn
Copy link
Contributor

vadimcn commented Jun 19, 2017

cc @michaelwoerister

@michaelwoerister
Copy link
Member

This has something to do with cargo or x.py sometimes not tolerating output on stdout. Compiling with --incremental will cause the -Zincremental-info flag being passed to rustc. @alexcrichton, do you know what this is about? Should we just print this debugging info to stderr?

@alexcrichton
Copy link
Member

alexcrichton commented Jun 19, 2017

Right now when we pass --message-format json to the compiler cargo expects stdout to be empty. This has been the original behavior since inception rust-lang/cargo#3000.

@matklad do you remember why this was an error? I remember there being discussion but I can't remember now. It seems fine to me to just ship this information to stdout like ususal?

@matklad
Copy link
Member

matklad commented Jun 19, 2017

do you remember why this was an error?

Yeah! The theory is that all info for humans should go to stderr, so that tools can safely parse JSON from stdout without the need to additional filtering (and so that humans, for example, could redirect stdout but still read status messages from stderr).

Should we just print this debugging info to stderr?

Yeah, I think stderr is a proper place for this kind of output.

@alexcrichton
Copy link
Member

Ah yes thanks for reminding me @matklad!

@michaelwoerister is it reasonable to do that? (switch to stderr for this output)

@michaelwoerister
Copy link
Member

I think so. The output is mostly meant for humans. We might have to update cargo-incremental but that shouldn't be a big deal. Is there a simple way to redirect println! to stderr?

@alexcrichton
Copy link
Member

Nowadays we've got eprintln!

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jun 22, 2017
…on-stderr, r=alexcrichton

Print -Zincremental-info to stderr instead of stdout.

Fixes rust-lang#42583.

The [cargo-incremental](https://github.com/nikomatsakis/cargo-incremental) tool probably does not need to be updated. It already merges stdout and stderr before parsing the compiler's output.

r? @alexcrichton
@Mark-Simulacrum Mark-Simulacrum added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Jun 23, 2017
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jun 23, 2017
…on-stderr, r=alexcrichton

Print -Zincremental-info to stderr instead of stdout.

Fixes rust-lang#42583.

The [cargo-incremental](https://github.com/nikomatsakis/cargo-incremental) tool probably does not need to be updated. It already merges stdout and stderr before parsing the compiler's output.

r? @alexcrichton
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

No branches or pull requests

6 participants