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`
cc @michaelwoerister
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?
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 https://github.com/rust-lang/cargo/pull/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?
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.
Ah yes thanks for reminding me @matklad!
@michaelwoerister is it reasonable to do that? (switch to stderr for this output)
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?
Nowadays we've got eprintln!
Most helpful comment
Nowadays we've got
eprintln!