cargo miri: can't disable colors

[matthiaskrgr]

It seems that since the last miri sync, stdout/stderr is printed with colors unconditionally?

This broke a bunch of icemaker regexes which fetch UB/ICEs from miri stdout and produced a couple of funny diffs:

-    "error_reason": "error: Undefined Behavior: type validation failed at .value: encountered uninitialized raw pointer",
+    "error_reason": "\u001b[0m   \u001b[0m\u001b[0m\u001b[1m\u001b[38;5;12m= \u001b[0m\u001b[0m\u001b[1mhelp\u001b[0m\u001b[0m: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior\u001b[0m",

I tried to disable colors but not even cargo --color=never miri run --color=never does work.

[matthiaskrgr]

probably since #2245 cc @saethlin ?

[RalfJung]

How does cargo forward --color=never to rustc? I would hope it stops passing diagnostic-rendered-ansi...

[RalfJung]

Oh no. Cargo seems to always pass --json=diagnostic-rendered-ansi,artifacts,future-incompat, even with --color=never. Does cargo then itself strip the ANSI from the JSON before putting it to the terminal...?

It looks like there is no way for the rustc driver to tell whether the user wanted output with or without colors? Cc @ehuss

[ehuss]

For caching purposes, cargo strips out the ANSI when color is disabled.

[RalfJung]

Ah, damnit. I just assumed cargo would not ask for colors if it doesn't want them...

I don't see a nice fix for this. The only option I see is for cargo-miri to parse --color itself (we usually prefer to refrain from parsing cargo's flags) and somehow out-of-band pass this information to Miri so that it knows to (not) put colors into the output. That's a pretty terrible hack. :(