Set RUST_BACKTRACE=0 in tests that include a backtrace in stderr

[Aaron1011]

This removes the implicit dependency on the environment variables set
when running ./x.py test

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

We might want to consider setting RUST_BACKTRACE=1 on CI to catch this kind of issue. This isn't the first time that running ./x.py test with RUST_BACKTRACE=1 has been broken by this kind of implicit dependency.

Alternatively, we could sanitize the environment variables used when running test - if something isn't set by a compile-test flag, then the test probably shouldn't be using it (excluding RUSTFLAGS, probably)

[Mark-Simulacrum]

I believe RUST_BACKTRACE=1 can have nonzero (and fairly significant) overhead on runtimes, or at least, we've had reports of such in the past, so I would be hesitant to set it on CI by default. I feel like fixing this when it comes up is not too hard (and it'd be good to document this in compiletest). I'd probably be fine with tests implicitly sanitizing RUST_BACKTRACE though so long as we have the two overrides: the test can manually say "always run me with, or without, a backtrace" and an override that globally sets RUST_BACKTRACE to something bypassing sanitization, though not the test-specific override probably.

[nikomatsakis]

@bors r+

(what @Mark-Simulacrum said)

[bors]

📌 Commit a336536 has been approved by nikomatsakis