const_prop makes RUST_CTFE_BACKTRACE unusable

[RalfJung]

The idea behind RUST_CTFE_BACKTRACE=1 was that it should only show a backtrace (of where a Miri error originates) when an error is actually shown to the user. And that worked fine when I implemented it. But since then, something changed in const_prop, and now I get thousands of backtraces even for crates with no errors, making the env var basically unusable. That is a big problem for debugging of the Miri engine.

Even RUST_CTFE_BACKTRACE=immediate shouldn't show so many errors, but that will be harder to do for const_prop which runs the CTFE engine on broken and non-monomorphized MIR (causing tons of problems, not just this).

@oli-obk @wesleywiser AFAIK you did a bunch of const_prop changes over the last few weeks/months; likely some of what you did is the culprit here. Any ideas?

[oli-obk]

Well. Const prop tries to eval things and if it fails it doesn't prop. The reason why there are many errors now is that we are actually using the interpcx instead of reimplementing its logic

[oli-obk]

I'm not sure how to reduce your noise. Maybe we can disable the env var before const prop and reenable after?

[RalfJung]

RUST_CTFE_BACKTRACE=1 only prints when print_backtrace is explicitly called -- somehow const_prop must be triggering that.

If that was fixed, things would still be slow because so many backtraces are captured, but at least the result should be readable.

[RalfJung]

The really fancy solution, but probably too magic, would be to determine if we are running inside a const_prop query and let that alter the behavior. AFAIK rustc uses thread-local storage so this could actually be done, but it might not be how that TLS is supposed to be used.

[RalfJung]

@oli-obk my guess is that the printing originates here:

rust/src/librustc_mir/transform/const_prop.rs

Line 258 in 6f70adc

let diagnostic = error_to_const_error(&self.ecx, error);

error_to_const_error calls print_backtrace, but that line does not always result in an error to be shown, right?