On some machines (as detected by Zed crash telemetry), toolchain discovery panics because a probed executable’s stdout is not valid UTF-8.
For example, we received:
b"\xCE\xC4\xBC\xFE\xB2\xBB\xB4\xE6\xD4\xDA: E:\\<redacted>\\-c\r\n"
This (according to my LLM) is GBK-encoding of 文件不存在: E:\<redacted>\-c, “File does not exist.”
I'm not sure why the executable appears to interpret -c as a filename, but I don't think we should panic on its output. Using String::from_utf8_lossy instead of String::from_utf8(...).unwrap() should address this.
On some machines (as detected by Zed crash telemetry), toolchain discovery panics because a probed executable’s stdout is not valid UTF-8.
For example, we received:
b"\xCE\xC4\xBC\xFE\xB2\xBB\xB4\xE6\xD4\xDA: E:\\<redacted>\\-c\r\n"This (according to my LLM) is GBK-encoding of
文件不存在: E:\<redacted>\-c, “File does not exist.”I'm not sure why the executable appears to interpret
-cas a filename, but I don't think we should panic on its output. UsingString::from_utf8_lossyinstead ofString::from_utf8(...).unwrap()should address this.