TERM=dumb is not respected for warnings in diagnostic annotations

[andreastt]

It appears the TERM=dumb environment variable is not respected by librustc_errors’ diagnostic annotations for warnings, hints, fatal errors, et al.

The below example of compiling a random program I’ve authored shows that the string “Compiling” correctly does not get colourised. This is because it uses termcolor’s ColorChoice::Auto which cancels colourisation because it checks if the terminal is dumb.

Farther down in the example, the string starting with “warning” emits a lot of escape sequences for colourisation.

For reference, so-called “dumb terminals” are terminals that only recognise a limited subset of escape sequences. In my particular case it is the monochrome rc shell.

% TERM=dumb cargo build
   Compiling build_const v0.2.0
   Compiling cfg-if v0.1.2
   Compiling matches v0.1.6
   Compiling cc v1.0.9
   Compiling num-traits v0.2.0
   Compiling version_check v0.1.3
   Compiling adler32 v1.0.2
   Compiling void v1.0.2
   Compiling unicode-normalization v0.1.5
   Compiling libc v0.2.39
   Compiling percent-encoding v1.0.0
   Compiling lazy_static v1.0.0
   Compiling safemem v0.2.0
   Compiling byteorder v1.2.1
   Compiling typeable v0.1.2
   Compiling language-tags v0.2.2
   Compiling traitobject v0.1.0
   Compiling semver-parser v0.7.0
   Compiling regex-syntax v0.4.1
   Compiling unicode-width v0.1.4
   Compiling httparse v1.2.3
   Compiling utf8-ranges v1.0.0
   Compiling strsim v0.6.0
   Compiling unicode-segmentation v1.1.0
   Compiling bitflags v1.0.1
   Compiling geckodriver v0.20.1 (file:///home/ato/src/gecko/testing/geckodriver)
   Compiling podio v0.1.5
   Compiling rustc-serialize v0.3.24
   Compiling log v0.4.1
   Compiling unreachable v1.0.0
   Compiling unicode-bidi v0.3.4
   Compiling crc v1.7.0
   Compiling base64 v0.6.0
   Compiling unicase v1.4.2
   Compiling num-traits v0.1.43
   Compiling miniz_oxide v0.1.2
   Compiling memchr v1.0.2
   Compiling rand v0.3.18
   Compiling num_cpus v1.7.0
   Compiling time v0.1.38
   Compiling term_size v0.3.0
   Compiling semver v0.6.0
   Compiling thread_local v0.3.5
   Compiling num-integer v0.1.35
   Compiling textwrap v0.9.0
   Compiling aho-corasick v0.6.3
   Compiling log v0.3.9
   Compiling rust-ini v0.10.2
   Compiling miniz_oxide_c_api v0.1.2
   Compiling bzip2-sys v0.1.6
   Compiling idna v0.1.4
   Compiling tempdir v0.3.5
   Compiling cookie v0.10.1
   Compiling msdos_time v0.1.5
   Compiling num-iter v0.1.34
   Compiling num v0.1.40
   Compiling mozprofile v0.3.0 (file:///home/ato/src/gecko/testing/mozbase/rust/mozprofile)
   Compiling mime v0.2.6
   Compiling regex v0.2.2
   Compiling clap v2.29.0
   Compiling chrono v0.2.25
   Compiling flate2 v1.0.1
   Compiling mozrunner v0.6.1 (file:///home/ato/src/gecko/testing/mozbase/rust/mozrunner)
   Compiling bzip2 v0.3.2
   Compiling url v1.7.0
   Compiling uuid v0.1.18
   Compiling zip v0.3.1
   Compiling hyper v0.10.13
   Compiling mozversion v0.1.3 (file:///home/ato/src/gecko/testing/mozbase/rust/mozversion)
   Compiling webdriver v0.35.0 (file:///home/ato/src/gecko/testing/webdriver)
�[0m�[1m�[33mwarning�[0m�[0m�[1m: variant is never constructed: `Quit`�[0m
�[0m  �[0m�[0m�[1m�[38;5;12m--> �[0m�[0mtesting/webdriver/src/server.rs:23:5�[0m
�[0m   �[0m�[0m�[1m�[38;5;12m|�[0m
�[0m�[1m�[38;5;12m23�[0m�[0m �[0m�[0m�[1m�[38;5;12m| �[0m�[0m    Quit�[0m
�[0m   �[0m�[0m�[1m�[38;5;12m| �[0m�[0m    �[0m�[0m�[1m�[33m^^^^�[0m
�[0m   �[0m�[0m�[1m�[38;5;12m|�[0m
�[0m   �[0m�[0m�[1m�[38;5;12m= �[0m�[0m�[1mnote�[0m�[0m: #[warn(dead_code)] on by default�[0m

    Finished dev [optimized + debuginfo] target(s) in 58.60 secs

[varkor]

I think this might have been fixed in #49191.

[andreastt]

It appears to still be a problem in Rust Nightly at the time of writing this. I’m making the assumption here that #49191 is in Nightly?

[sfackler]

#49191 only changed the behavior of the bootstrap wrapper when building rust itself, so it's unrelated to this issue.

[sfackler]

Which version of Rust/OS are you using? I can't seem to reproduce this on macOS with either 1.26.0 or 1.27.0-nightly (acd3871 2018-05-10).

[andreastt]

The test case for this is that TERM=dumb cargo build does not output any colours for diagnostic output. In Terminal.app you would not see the above escape sequences because it isn’t a dumb terminal.

I’ve tested with the following rustc versions:

% rustc --version
rustc 1.27.0-nightly (acd3871ba 2018-05-10)

% rustc --version
rustc 1.26.0 (a77568041 2018-05-07)

[sfackler]

The test case for this is that TERM=dumb cargo build does not output any colours for diagnostic output. In Terminal.app you would not see the above escape sequences because it isn’t a dumb terminal.

Yep, that's correct.

[sfackler]

Also unable to reproduce on Debian Stretch:

[andreastt]

I ran some further tests and it appears the escape sequences only appear when the diagnostic output comes from a crate dependency.

The warning above stems from the webdriver crate, which has an unused variant in an enum.

[andreastt]

… and apparently only for warnings.

I’m trying to devise a test case.

[andreastt]

Sorry, I was a bit quick on the trigger in my previous comment. The colourisation appears to only happen for warnings.

It is reproducible on Nightly with a program that the compiler will emit a warning for:

pub fn foo() {
    let bar = "42";
}

I’ve put this program (along with the necessary cargo files) in a gist at https://gist.github.com/andreastt/498e3abe08a6a16123e99c02a77c2c73.

Running it, I see the following output in a dumb terminal:

% git clone https://gist.github.com/andreastt/498e3abe08a6a16123e99c02a77c2c73
Cloning into '498e3abe08a6a16123e99c02a77c2c73'...
remote: Counting objects: 4, done.        
remote: Compressing objects: 100% (3/3)           
remote: Compressing objects: 100% (3/3), done.        
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0        
Unpacking objects: 100% (4/4), done.
% cd 498e3abe08a6a16123e99c02a77c2c73/
% TERM=dumb cargo build
   Compiling foo v0.1.0 (file:///tmp/498e3abe08a6a16123e99c02a77c2c73)
�[0m�[1m�[33mwarning�[0m�[0m�[1m: unused variable: `bar`�[0m
�[0m �[0m�[0m�[1m�[38;5;12m--> �[0m�[0mfoo.rs:2:9�[0m
�[0m  �[0m�[0m�[1m�[38;5;12m|�[0m
�[0m�[1m�[38;5;12m2�[0m�[0m �[0m�[0m�[1m�[38;5;12m| �[0m�[0m    let bar = "42";�[0m
�[0m  �[0m�[0m�[1m�[38;5;12m| �[0m�[0m        �[0m�[0m�[1m�[33m^^^�[0m�[0m �[0m�[0m�[1m�[33mhelp: consider using `_bar` instead�[0m
�[0m  �[0m�[0m�[1m�[38;5;12m|�[0m
�[0m  �[0m�[0m�[1m�[38;5;12m= �[0m�[0m�[1mnote�[0m�[0m: #[warn(unused_variables)] on by default�[0m

    Finished dev [unoptimized + debuginfo] target(s) in 0.56s

[andreastt]

And here is what it looks like in Terminal.app:

[sfackler]

Are you sure you don't have any rogue environment variables or .cargo/configs or something?

[andreastt]

@sfackler You were entirely correct!

I iteratively unset each environment variable listed by env(1) and found that RUSTC_WRAPPER=sccache caused the problem. I am assuming the problem is that sccache does not inherit the current environment when it invokes rustc again.

Sorry for wasting your name, but you did help me narrow down the problem.