ANSI colors not closed on cargo test

[djrenren]

Ran into a build failure during cargo test. The red color in the terminal didn't terminate, leaving me a red terminal and an empty feeling in my soul.

[alexcrichton]

Does this reproduce reliably for you? I suspect that this may be because there are two compilations occurring in parallel. If you run cargo build -j1 does it reproduce?

[retep998]

I've ran into similar issues with colors using the windows console and using -j1 always resolved those problems.

[toqueteos]

I was running cargo test nbt_ -- --nocapture (which btw doesn't apply --nocapture) and got this:

I'm on Win 8.1 x64.

$ cargo -V
cargo 0.0.1-pre-nightly (453ae9f 2015-01-29 00:56:56 +0000)

$ rustc -V
rustc 1.0.0-nightly (c5961ad06 2015-01-28 21:49:38 +0000)

[lilith]

Has anyone seen duplication happen at color change boundaries?

$ cargo -V
cargo 0.4.0-nightly (0faebf2 2015-07-20) (built 2015-07-20)
$ rustc -V
rustc 1.3.0-nightly (118a5c4c3 2015-07-21)

[alexcrichton]

Yeah this'll happen because Cargo is running two instances of the compiler in parallel and they're both producing error messages. The ANSI codes don't play well when emitted concurrently, causing weird coloration and/or interleaving.

[SimonSapin]

Random idea to try to fix this, if it is indeed caused by parallel rustc’s writing to the same terminal unsynchronized:

• Whenever rustc (or rustdoc or another tool) uses ANSI codes (or equivalent), make sure they’re reset before the end of the line. If more than one line needs to be colored the same, do the "unnecessary" reset and re-configure at the next line.
• When Cargo calls rustc (or another tool), rather than inherit stdout and stderr, set up pipes so that Cargo can do some synchronization, reading and relaying one line at a time. An easy-ish way to do this might involve a number of threads doing blocking reads and sending lines to a std::sync::mpsc::channel. (Since doing something like POSIX’s select (2) cross-platform might be tricky.)

[alexcrichton]

I think that may work for Unix, but unfortunately I don't think it'd work for Windows. The colorization I think is a global state of the terminal itself rather than an encoded part of the output stream (yay!). Not to say that it shouldn't be done, but it unfortunately wouldn't close the issue :(

[retep998]

Color is not a state of the console, but rather the console buffer. You can create multiple console buffers, although only one is displayed at a time. You can pass one of these background console buffers to the spawned rustc, and when its done, write that output to the primary buffer.

[retep998]

An alternative cross platform way is to have rustc output warnings and errors in a machine readable format and then have Cargo responsible for formatting the errors and warnings in a human readable format with colors.

[alexcrichton]

I've opened rust-lang/rust#32486 after discussing with @brson which would hopefully provide a nice way to mitigate this in the meantime.

[codyps]

I'd like to recommend a more complete approach to solving this, and other inter-mixed output issues

Buffer all output from a command, when run in parallel, before displaying it.

This is the approach another build tool (ninja-build takes, and it has the added benefit of allowing cargo to make absolutely clear to the user which output is associated with which command (ie: it can print the command invocation above the output when a warning or error occurs).

[retep998]

Buffer all output from a command, when run in parallel, before displaying it.

@jmesmon The only problem with that is you'd need to be really clever to make it preserve colors with the Windows console which uses API calls instead of ansi escape codes. As I mentioned above we could either spawn new console buffers for each process and then copy out the output, or we could have rustc emit a machine readable format and then cargo can add colors to that when printing it out.

[alexcrichton]

I believe this has since been fixed in the compiler, so closing.