report status to stderr instead of stdout

[matklad]

All status messages are printed to stderr instead of stdout now.

This changes exactly three letters of code and breaks 211 tests 😨

I will hopefully fix all the tests here, but I decided to submit PR early in case somebody comes up with a less laborious way to do this.

Fixes #1473, #2661

[rust-highfive]

r? @alexcrichton

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

[matklad]

breaks 211 tests

... on the stable compiler. There should be even for failures for nightly

[matklad]

91 failures left :)

[matklad]

Hm, I found an interesting phenomena: some tests before this changed asserted stdout and ignored stderr although some warnings were printed to stderr. When converting with_stdout to with_stderr these test fail because there is more output. One way to fix them is to add warnings to the expected output, like I did in this commit. But is this really the best way? Could changing with_stderr to with_stderr_contains be a better fix? I think it would, because it makes tests more robust.

[alexcrichton]

@matklad yeah that's probably a split between "intentionally ignored", "too lazy to write out the output", or "oops forgot to assert that output". It should be fine to either add the assertions or switch to with_stdout_contains.

Also cc @rust-lang/tools, a somewhat large-ish semantic change to Cargo!

[matklad]

Also cc @rust-lang/tools, a somewhat large-ish semantic change to Cargo!

Nice, I indeed feel a little uneasy because of the scope of the change (Although I personally think that stderr is the right stream for the status messages). I'll then wait for an explicit approval before I continue fixing the tests :)

[nrc]

+1 for more disciplined use of stderr/out

[brson]

I agree that stderr is the right place for status messages. How will this affect cargo run -q (which I use because cargo prints to stdout)? I guess it will continue to not print things to stderr? Is that still useful?

[alexcrichton]

@brson in theory it won't affect cargo run -q as Cargo will continue to not print anything.

[alexcrichton]

Discussed during tools triage we were all on board, so let's do this! Wanna fix up the few remaining tests @matklad and I'll merge?

[matklad]

Wanna fix up the few remaining tests @matklad and I'll merge?

Yeah, I'll do it, but I can't give a precise ETA (this weak perheps?). The remaining tests most likely all require some manual intervention.

[alexcrichton]

Ah yeah no worries, and if you run out of time I can help out as well

[matklad]

@alexcrichton this tests looks a bit strange. Looks like it should set and read an environmental variable, but it actually is never asserted (and "unused function foo" is printed during the compilation).

Perhaps the test doesn't test what it is supposed to?

[alexcrichton]

I believe the env! macro fails compilation if the env var isn't defined

[matklad]

@alexcrichton I think I have fixed all the tests except the cross compile ones (one does not simply link stuff on nixos :) ). Can you please finish the work here? I think the commits should be squashed before merge, but it may be simpler to review them one by one.