Driver logging: disable colors when logging to file

[RalfJung]

When debugging a large Miri trace, I like to put the trace into a file that I can analyze and search through in an editor. Unfortunately, since the recent logging changes, that leads to a lot of garbage in the file:

2:rustc│ │ │ │ │ │ ├─�[2m0�[0m�[2mms�[0m �[1;32m INFO�[0m �[2mrustc_mir::interpret::step�[0m Retag([fn entry] _1)
2:rustc│ │ │ │ │ │ ├─�[2m0�[0m�[2mms�[0m �[1;32m INFO�[0m �[2mrustc_mir::interpret::step�[0m StorageLive(_2)
2:rustc│ │ │ │ │ │ ├─�[2m0�[0m�[2mms�[0m �[1;32m INFO�[0m �[2mrustc_mir::interpret::step�[0m StorageLive(_3)
2:rustc│ │ │ │ │ │ ├─�[2m0�[0m�[2mms�[0m �[1;32m INFO�[0m �[2mrustc_mir::interpret::step�[0m _3 = move _1
2:rustc│ │ │ │ │ │ ├─�[2m0�[0m�[2mms�[0m �[1;32m INFO�[0m �[2mrustc_mir::interpret::step�[0m Retag(_3)
2:rustc│ │ │ │ │ │ ├─�[2m0�[0m�[2mms�[0m �[1;32m INFO�[0m �[2mrustc_mir::interpret::step�[0m _2 = std::mem::ManuallyDrop::<std::boxed::Box<T, A>>::new(move _3) -> [return: bb1, unwind: bb5]
2:rustc│ │ │ │ │ │ ├┐�[2mrustc_mir::interpret::eval_context�[0m::�[1;32mframe�[0m std::boxed::Box::<alloc::collections::btree::node::LeafNode<std::string::String, i32>>::into_unique
2:rustc│ │ │ │ │ │ │└┐�[2mrustc_mir::interpret::eval_context�[0m::�[1;32mframe�[0m std::mem::ManuallyDrop::<std::boxed::Box<alloc::collections::btree::node::LeafNode<std::string::String, i32>>>::new
2:rustc│ │ │ │ │ │ │ ├─�[2m0�[0m�[2mms�[0m �[1;32m INFO�[0m �[2mrustc_mir::interpret::step�[0m // executing bb0
2:rustc│ │ │ │ │ │ │ ├─�[2m0�[0m�[2mms�[0m �[1;32m INFO�[0m �[2mrustc_mir::interpret::step�[0m Retag([fn entry] _1)
2:rustc│ │ │ │ │ │ │ ├─�[2m0�[0m�[2mms�[0m �[1;32m INFO�[0m �[2mrustc_mir::interpret::step�[0m StorageLive(_2)
2:rustc│ │ │ │ │ │ │ ├─�[2m0�[0m�[2mms�[0m �[1;32m INFO�[0m �[2mrustc_mir::interpret::step�[0m _2 = move _1
2:rustc│ │ │ │ │ │ │ ├─�[2m0�[0m�[2mms�[0m �[1;32m INFO�[0m �[2mrustc_mir::interpret::step�[0m Retag(_2)

Looks like the color escape sequences are printed even when redirecting to a file. This makes working with the logfile much harder than it was before. Is there a way to fix that?

Cc @oli-obk

[oli-obk]

This is the fault of

rust/compiler/rustc_driver/src/lib.rs

Line 1289 in 35debd4

.with_ansi(true)

I should be checking for whether the terminal supports colors before activating colors

[oli-obk]

A workaround until then is to use https://superuser.com/a/380778

[camelid]

How can I run miri from the rust repo? (i.e. built using ./x.py build)

[RalfJung]

You can run the test suite with ./x.py test --stage 0 src/tools/miri, but that's not what you were asking... that's not supported yet unfortunately: #76666

[RalfJung]

Until then, you'll have to resort to this.

Some of the x.py commands might need adjusting though as x.py changed.

[camelid]

Ah, thanks! I forgot about that part of the docs :)

[camelid]

Hmm, I'm getting this error:

error[E0463]: can't find crate for `rustc_attr`
  --> src/lib.rs:14:1
   |
14 | extern crate rustc_attr;
   | ^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

I'm using the latest master rustc and the latest miri. Is miri broken right now?

EDIT: Oh, I think I need --stage 2.

[RalfJung]

Yeah looks like you are using the wrong stage or so. The docs are from back when stage 2 was the default...

[RalfJung]

@oli-obk @camelid I'm afraid the problem was not solved by that PR. When I run Miri like this locally

MIRI_LOG=info,miri::stacked_borrows=trace ./miri run /tmp/test.rs -Zmiri-track-raw-pointers 2> log

I still get all the ANSI codes in that logfile, which makes the file very hard to work with.

[RalfJung]

Looks like the code tests stdout_isatty, but logging goes to stderr so this is the wrong test.

[camelid]

Hmm, I guess I didn't notice any issues because I always redirect stderr to stdout and then view that.

[camelid]

Working on a fix.

[RalfJung]

Yeah, for now using &>log to redirect both to the logfile is an okay work-around.

[jyn514]

@RalfJung FYI you can view the original color with less -R, which prints them directly to the terminal. That doesn't work in an editor, though.