Skip to content

Setting MIRI_BACKTRACE should not affect CTFE #53355

Closed
@RalfJung

Description

@RalfJung
Member

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

Cc @oli-obk

Activity

oli-obk

oli-obk commented on Aug 15, 2018

@oli-obk
Contributor

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

RalfJung commented on Aug 15, 2018

@RalfJung
MemberAuthor

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

oli-obk commented on Aug 15, 2018

@oli-obk
Contributor

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.

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

RalfJung

RalfJung commented on Aug 15, 2018

@RalfJung
MemberAuthor

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

oli-obk commented on Aug 15, 2018

@oli-obk
Contributor

yea, that seems a good solution.

RalfJung

RalfJung commented on Aug 15, 2018

@RalfJung
MemberAuthor

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

oli-obk commented on Aug 15, 2018

@oli-obk
Contributor

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

RalfJung commented on Aug 15, 2018

@RalfJung
MemberAuthor

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

RalfJung commented on Aug 23, 2018

@RalfJung
MemberAuthor

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...

self-assigned this
on Sep 20, 2018
RalfJung

RalfJung commented on Sep 20, 2018

@RalfJung
MemberAuthor

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

added a commit that references this issue on Oct 28, 2018

Auto merge of #54487 - RalfJung:ctfe-backtrace, r=oli-obk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @RalfJung@oli-obk

      Issue actions

        Setting MIRI_BACKTRACE should not affect CTFE · Issue #53355 · rust-lang/rust