1357537 - mozbuild should not apply ANSI escape codes to output when TERM=dumb

Status: NEW

(Firefox Build System :: General, defect)

Description

[Jim Blandy :jimb]

mozbuild currently applies ANSI color escape sequences to the compiler output. It should not do so when TERM=dumb.

When running a compilation within Emacs, the escape codes interfere with Emacs's ability to match error and warning messages, preventing it from popping up the source position of the error. Emacs sets the TERM environment variable to 'dumb' for compilation subprocesses. It's inappropriate for mozbuild to be producing escape codes inappropriate to the current TERM value anyway.

(I don't actually know whether it's mozbuild or the compilers themselves adding the escape codes. That's not really the point.)

I'm familiar with the workaround in bug 1171610 comment 28. A user capable of hacking their compilation-filter-hook is capable of setting their TERM variable correctly for compilation processes.

Comment 1

[Gregory Szorc [:gps]]

So, mach doesn't just hard code the color codes: the terminfo database is consulted based on the value of TERM and appropriate sequences are emitted, if appropriate.

But if I run `TERM=dummy tput longname` terminfo says "unknown terminal." So something weird is happening.

It looks like the issue is in clang and possibly gcc. In config.mk, we enable color output from the compiler if mach's stdin is connected to a TTY and we detected color flags support in configure (which we should always do for gcc and clang). TERM should be getting passed through to the compiler.

What Clang is doing is ignoring that TERM=dummy doesn't have terminfo support and appears to be falling back to some default. I can reproduce this by invoking clang directly. e.g. from objdir/config/external/icu/common:

$ TERM=dummy /usr/bin/clang -std=gnu99 -o udataswp.o -c -I/home/gps/src/firefox/objdir/dist/system_wrappers -include /home/gps/src/firefox/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DU_COMMON_IMPLEMENTATION -DLOCALE_SNAME=92 -DUCONFIG_NO_BREAK_ITERATION -DUCONFIG_NO_TRANSLITERATION -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_LEGACY_CONVERSION -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 -DU_CHARSET_IS_UTF8 -I/home/gps/src/firefox/config/external/icu/common -I/home/gps/src/firefox/objdir/config/external/icu/common -I/home/gps/src/firefox/intl/icu/source/i18n -I/home/gps/src/firefox/objdir/dist/include  -I/home/gps/src/firefox/objdir/dist/include/nspr -I/home/gps/src/firefox/objdir/dist/include/nss       -fPIC  -include /home/gps/src/firefox/objdir/mozilla-config.h -DMOZILLA_CLIENT -MD -MP -MF .deps/udataswp.o.pp -Qunused-arguments  -Qunused-arguments -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wclass-varargs -Wloop-analysis -Wstring-conversion -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wformat -Wno-gnu-zero-variadic-macro-arguments -fno-strict-aliasing -fno-math-errno -pthread -pipe  -g -Os -fno-omit-frame-pointer   -fcolor-diagnostics  /home/gps/src/firefox/intl/icu/source/common/udataswp.c

<prints color in warning>

But if I remove -fcolor-diagnostics, TERM=xterm-256color (my shell's default) results in color but TERM=dummy does not. So, it appears that -fcolor-diagnostics forcefully enables color, ignoring invalid TERM values and assuming some default.

I'm not sure where the code is that does the unknown TERM fallback. But I'm pretty certain it is in LLVM not Clang.

I guess our workaround here is to change the build system to not pass the "force color" argument to Clang (and possibly GCC) if TERM doesn't resolve to a known terminal.