Compiler diagnostics are replayed in the wrong language (locale is not in the cache key)

A cache entry stores the compiler's stdout and stderr and sccache replays them on a hit, but nothing that selects the diagnostic language is part of the key. Two compilations that differ only in locale share an entry, and the second one prints the first one's messages.

Reproduces on Linux with gcc (needs the gcc translations, e.g. gcc-13-locales on Ubuntu, and de_DE.UTF-8 generated):

printf 'int f(void){ int x; return 1; }\n' > w.c
sccache --stop-server
sccache gcc -c -Wall w.c -o /dev/null          # miss, English warning
LC_ALL=de_DE.UTF-8 sccache gcc -c -Wall w.c -o /dev/null

The second is a cache hit and prints the English warning, where bare gcc would print "Warnung: Variable »x« wird nicht verwendet".

LC_CTYPE alone is enough to change the bytes even with the language unchanged: gcc quotes with U+2018/U+2019 under a UTF-8 character type locale and with an ASCII apostrophe otherwise.

On MSVC this is not only cosmetic. ninja's deps = msvc matches msvc_deps_prefix against the compiler's output, so replaying a prefix in the wrong language leaves its dependency graph empty. Confirmed on Japanese Windows: a VSLANG=1033 build was a cache hit and printed the Japanese diagnostics stored by an earlier one.

A fix that hashes VSLANG and the gettext variables, in both the object and preprocessor cache keys, is on https://github.com/beru/sccache/tree/cache-key-diagnostic-locale. It costs cache sharing between machines with different locales, so it may want discussion before a PR.

Generated with Claude Code