rustc sometimes emits exclusively human-readable output on stdout. Moreover, it sometimes produces machine-readable output on stderr. It should be the other way around, and at least output writing should be principled.
When compiling a bin target helloworld:
On stdout:
This would interfere in parsing JSON messages (--error-format json), for example from Clippy. If only they weren’t mistakenly written on stderr, too ... It seems very simple to fix such little slip-ups, but I couldn’t track down the offending code for this instance.
Another sample of the same issue, from a different angle:
rustc --error-format json
Prints on stderr:
{"message":"no input filename given","code":null,"level":"error","spans":[],"children":[],"rendered":"error: no input filename given\n\n"}
I propose, first, that we decide to guarantee that all JSON will ever be printed on stdout exclusively, and all the rest on stderr exclusively. Second, to implement this by making the appropriate fixes across rustc, Cargo and Clippy.
Meta
rustc 1.25.0-nightly (3ec5a99 2018-02-14)
Related #36516
rustcsometimes emits exclusively human-readable output on stdout. Moreover, it sometimes produces machine-readable output on stderr. It should be the other way around, and at least output writing should be principled.When compiling a bin target
helloworld:On stdout:
This would interfere in parsing JSON messages (
--error-format json), for example from Clippy. If only they weren’t mistakenly written on stderr, too ... It seems very simple to fix such little slip-ups, but I couldn’t track down the offending code for this instance.Another sample of the same issue, from a different angle:
Prints on stderr:
I propose, first, that we decide to guarantee that all JSON will ever be printed on stdout exclusively, and all the rest on stderr exclusively. Second, to implement this by making the appropriate fixes across
rustc, Cargo and Clippy.Meta
rustc 1.25.0-nightly (3ec5a99 2018-02-14)
Related #36516