Print a backtrace in const eval if interrupted

[saethlin]

Demo:

#![feature(const_eval_limit)]
#![const_eval_limit = "0"]

const OW: u64 = {
    let mut res: u64 = 0;
    let mut i = 0;
    while i < u64::MAX {
        res = res.wrapping_add(i);
        i += 1;
    }
    res
};

fn main() {
    println!("{}", OW);
}

╭ ➜ ben@archlinux:~/rust
╰ ➤ rustc +stage1 spin.rs 
^Cerror[E0080]: evaluation of constant value failed
 --> spin.rs:8:33
  |
8 |         res = res.wrapping_add(i);
  |                                 ^ Compilation was interrupted

note: erroneous constant used
  --> spin.rs:15:20
   |
15 |     println!("{}", OW);
   |                    ^^

note: erroneous constant used
  --> spin.rs:15:20
   |
15 |     println!("{}", OW);
   |                    ^^
   |
   = note: this note originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to previous error

For more information about this error, try `rustc --explain E0080`.

[rustbot]

r? @Mark-Simulacrum

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

[oli-obk]

Yea, this is exactly what I wanted. Do any of the new deps have problematic licenses? Otherwise seems fine to just add them to the list of allowed crates.

[saethlin]

ctrlc is MIT or Apache-2.0, nix is MIT. I'll try to spruce up the implementation then get this reviewed.

Jynn said Mark has previously been uncomfortable with signal handlers or atexit code, so I'd prefer Mark approve this before it goes in (got lucky with the random selection I suppose).

[Mark-Simulacrum]

This seems broadly fine to me, my main concern here is that we don't write custom code where we need to be worried about signal safety etc to a great degree. But it seems like that's not being done here, which is good.

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[saethlin]

Just so everyone follows along, we recently added a mechanism like this to Miri: rust-lang/miri#2899

Since we ctrlc::set_hook inside rustc_driver::main, Miri should probably keep installing its own hook, but it might be nice to use the static inside rustc_*. cc @RalfJung (ah duh the bot has pinged you already, well now you know I really care about you knowing :p )

[oli-obk]

Miri should probably keep installing its own hook, but it might be nice to use the static inside rustc_*.

You could do this change in this PR, subtrees ftw

[RalfJung]

You could do this change in this PR, subtrees ftw

We should first push Miri changes to rustc though or else we'll get conflicts.

[bors]

☔ The latest upstream changes (presumably #111867) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

r=me on the interpreter changes. Do we still need to get some approval for the new rustc dependencies?

[bors]

☔ The latest upstream changes (presumably #111933) made this pull request unmergeable. Please resolve the merge conflicts.

[saethlin]

I'm happy to wait for @Mark-Simulacrum to swing by again and offer an opinion :)

[Mark-Simulacrum]

@bors r=RalfJung

[bors]

📌 Commit 38a5fee has been approved by RalfJung

It is now in the queue for this repository.

[RalfJung]

@bors r-

[RalfJung]

r=me with some last nits, but we'll have to figure out this approval for the new dependency

[RalfJung]

I meant to ask about all the new dependencies, not just the one. :)

[bors]

☔ The latest upstream changes (presumably #122611) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Some changes occurred in run-make tests.

cc @jieyouxu

[saethlin]

@bors r=RalfJung

[bors]

📌 Commit 9e0d1a3 has been approved by RalfJung

It is now in the queue for this repository.

[bors]

⌛ Testing commit 9e0d1a3 with merge c98ea0d...

[bors]

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing c98ea0d to master...

[rust-timer]

Finished benchmarking commit (c98ea0d): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.3%	[3.4%, 5.1%]	2
Improvements ✅ (primary)	-1.6%	[-3.2%, -0.9%]	12
Improvements ✅ (secondary)	-2.3%	[-3.1%, -1.2%]	16
All ❌✅ (primary)	-1.6%	[-3.2%, -0.9%]	12

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-1.5%, -0.4%]	6
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.7%	[-1.5%, -0.4%]	6

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 671.315s -> 675.795s (0.67%)
Artifact size: 315.65 MiB -> 315.67 MiB (0.00%)

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

  PR_MESSAGE: Automation to keep dependencies in `Cargo.lock` current.
following is the output from `cargo update`:
  COMMIT_MESSAGE: cargo update 
##[endgroup]
Starting download for Cargo-lock
##[error]Unable to find any artifacts for the associated workflow