Setting MIRI_BACKTRACE should not affect CTFE

[RalfJung]

MIRI_BACKTRACE should configure miri, but should not have an effect on CTFE that's part of normal rustc operation.

Cc @oli-obk

[oli-obk]

That seems very hard to differentiate. And I sometimes did actually need the MIRI_BACKTRACE for figuring out problems in CTFE.

Since you probably just don't want all the noise from CTFE while running miri, you can std::env::set_var the variable automatically in miri, this will happen after the compilation is done, so you'll only see miri backtraces.

[RalfJung]

That seems very hard to differentiate.

How so? I imagined moving the decision about whether to backtrace into the machine trait. miri would base it in MIRI_BACKTRACE. CTFE would base it on something else; maybe CTFE_BACKTRACE?

[oli-obk]

the backtrace is generated in the From impl of EvalError. There's no Machine available and it would be very painful to thread it through.

rust/src/librustc/mir/interpret/error.rs

Lines 124 to 126 in 81cfaad

	impl<'tcx> From<EvalErrorKind<'tcx, u64>> for EvalError<'tcx> {
	fn from(kind: EvalErrorKind<'tcx, u64>) -> Self {
	match env::var("MIRI_BACKTRACE") {

[RalfJung]

Oh, dang...

you can std::env::set_var the variable automatically in miri, this will happen after the compilation is done, so you'll only see miri backtraces.

So what would the UI be? We change librustc to look for CTFE_BACKTRACE, and then miri wil check for MIRI_BACKTRACE and set CTFE_BACKTRACE before execution starts?

[oli-obk]

yea, that seems a good solution.

[RalfJung]

We also need to fix the way backtraces are printed... they should not be printed immediately when the error is converted, but only later when the error is shown to the user. We do still create errors that we never act on, and finding the right backtrace is pretty hard ATM.

[oli-obk]

We used to do that. I changed it to the current system when I got rid of the old CTFE error enum. we can probably add an optional field to the EvalError type which stores the backtrace as long as it's not compared, hashed,. .. or interacts with any traits implemented for the type

[RalfJung]

Okay... yeah I think we have to change it. Right now, for my debugging, MIRI_BACKTRACE is useless; all it does is produce several thousand lines of backtraces.

[RalfJung]

I think I'd like the same for RUST_LOG... something that makes miri set that variable once compilation is done.

Of course, in a query-based compiler, I don't even know what that means...

[RalfJung]

I am working on that (PR is blocked by #53821 (comment))