Improve diagnostics of evaluation of constant value failed errors

[Herschel]

Given the following code:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=0a24628f94a07753519f86993f792ddb

#[cfg(target_arch = "x86_64")]
fn main() {
    use std::arch::x86_64::*;
    unsafe {
        let a: __m128 = _mm_setzero_ps();
        let b: __m128 = _mm_setzero_ps();
        let _blended = _mm_blend_ps(a, b, 0x33);
    }
}

The current output is:

error[E0080]: evaluation of constant value failed
 --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/macros.rs:8:17
  |
8 |         let _ = 1 / ((IMM >= MIN && IMM <= MAX) as usize);
  |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to divide `1_usize` by zero

error: internal compiler error: src/tools/miri/src/diagnostics.rs:94:21: This error should be impossible in Miri: encountered constants with type errors, stopping evaluation

Pointing to these lines inside std::arch:
https://github.com/rust-lang/stdarch/blob/master/crates/core_arch/src/macros.rs#L5-L10

The error message only points to the final site where const evaluation failed in std::arch. Ideally the error would point higher to the calling code that caused the const evaluation. If this error occurs deep within the dependency graph of a project, there's no easy way to deduce which crate is making the problematic call and causing the build to fail. I resorted to grepping .cargo for arch:: and lots of trial and error. Neither --verbose nor RUST_BACKTRACE were helpful. Someone later mentioned that RUSTC_LOG=rustc_mir::interpret=info could help track it down, but this is user-unfriendly.

Impacting this issue in the wild:
ejmahler/RustFFT#74
rust-lang/stdarch#1159

1.54.0-nightly

(2021-05-09 ca82264ec7556a6011b9)

[Mark-Simulacrum]

Possibly a regression as a result of the stdarch PR landing, tagging as such so we eventually investigate.

[Amanieu]

cc @rust-lang/wg-const-eval

[apiraino]

I've tried bisecting this error, seems to point out to PR #83278

searched nightlies: from nightly-2021-04-01 to nightly-2021-05-11
regressed nightly: nightly-2021-05-09
searched commits: from 770792f to 881c1ac
regressed commit: 881c1ac

bisected with cargo-bisect-rustc v0.6.0

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start=2021-04-01 --regress error 

[oli-obk]

Oh wow, that is the error when run with miri. The error in regular builds has no information beyond "const eval failed"

[oli-obk]

Ah, this is a post-monomorphization error. This is already being tracked in #73961

While we want to improve post-monomorphization errors, the "right" way to do this is const_evaluatable_checked. Unfortunately that feature is nowhere near ready to even be used unstably.

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-high

[Amanieu]

Just to clarify: stdarch was changed to reject invalid const operands to intrinsics which were previously accepted. This was done to align with the behavior of these intrinsics in C compilers.

However the method to do this involves post-monomorphization errors which unfortunately produce very poor error messages (just "const eval failed" with no line info).

[oli-obk]

cross post from zulip

I have an idea for how to create a backtrace for post monomorphization errors. It's not great, but better than the status quo: in the monomorphization collector, we already have that stack available, we just can't feed it into any queries or whatever is producing errors. So we wrap all possibly erroring calls with something that checks the error count before and after the call. If the count went up, print the stack mentioning that the last error occurred at this monomorphization stack. To reduce the noise, only do that if the current item is generic

[oli-obk]

I'd be happy to mentor someone who wants to implement that

[lqd]

@oli-obk I would like to help :)

[bjorn3]

re #85155 (comment): I think that would require evaluating the required consts of a MIR body inside the mono item collector.

[Mark-Simulacrum]

This was a regression but is no longer tracked for a particular release.

[pnkfelix]

Current output as of 1.66:

error[[E0080]](https://doc.rust-lang.org/stable/error-index.html#E0080): evaluation of `core::core_arch::macros::ValidateConstImm::<51, 0, 15>::VALID` failed
  |
  = note: this error originates in the macro `$crate::panic::panic_2021` which comes from the expansion of the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51>`
 --> src/main.rs:7:24
  |
7 |         let _blended = _mm_blend_ps(a, b, 0x33);
  |                        ^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0080`.
error: could not compile `playground` due to previous error

This seems leaps and bounds better than it was when this was first filed...

[pnkfelix]

@lqd and @oli-obk: do you think we can close this? (and, if necessary, open a separate tracking issue outlining what further changes you think are necessary to improve error backtraces from const-eval?)

[pnkfelix]

(I suppose at minimum we should add a regression test, to ensure we catch if the output gets worse...)

[oli-obk]

Oh yea, this is fixed now

[oli-obk]

This was fixed in #104449