Cargo buffers stdout even with TERM=dumb

[RalfJung]

Problem

Even with TERM=dumb, cargo buffers stderr stdout, meaning I do not see things printed to stdout without a trailing \n.

For Miri, we use cargo rustc set up RUSTC_WRAPPER such that we can intercept the call that builds a binary, to instead run it with Miri. Unfortunately, if the application prints to stdout, that output is buffered by Cargo. This is a problem in particular when running a test suite, because it means I cannot see which test is taking long when the test suite just stops.

Possible Solution(s)

When Cargo prints no progress bar, it should leave stdout of the running application entirely unmodified, and not introduce any additional line buffering.

Notes

Output of cargo version: cargo 1.34.0-nightly (2458180 2019-01-27)

[RalfJung]

This is likely related to cargo capturing JSON from the compiler.

[ehuss]

It is unrelated to JSON which uses a separate code path (only if --message-format=json is used). It is buffered so that when multiple compilers are running at the same time that their output doesn't interleave with one another. It's not a perfect solution, but it's a tricky problem (rustc on Windows uses a global lock to accomplish this).

I'm not sure I understand the issue. Is miri sending information without a trailing \n?

[RalfJung]

Miri runs an arbitrary program, and that program sends information without a trailing \n. Specifically, it is running the libtest harness (without concurrency), which uses that to show the name of the currently running test -- very useful when working with Miri and a test takes 5min and I want to know which test is slow.

[Ark-kun]

Python has an "unbuffered" option - python -u. Perhaps cargo can do this as well.

https://docs.python.org/3/using/cmdline.html#cmdoption-u

[RalfJung]

FWIW Miri these days uses target.runner to control what happens when the executable is run, so we no longer have this problem.

[epage]

Without a use case needing this anymore, I'm going to go ahead and close this. If there is a reason for us to re-evaluate this, let us know!