Repository navigation
Improve diagnostics of evaluation of constant value failed errors #85155
Description
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)
Activity
Mark-Simulacrum commentedon May 10, 2021
Possibly a regression as a result of the stdarch PR landing, tagging as such so we eventually investigate.
Amanieu commentedon May 11, 2021
cc @rust-lang/wg-const-eval
apiraino commentedon May 11, 2021
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:
oli-obk commentedon May 11, 2021
Oh wow, that is the error when run with miri. The error in regular builds has no information beyond "const eval failed"
oli-obk commentedon May 11, 2021
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 commentedon May 13, 2021
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.
@rustbot label -I-prioritize +P-high
8 remaining items
Rollup merge of rust-lang#85633 - lqd:stackless_span_stacks, r=oli-obk
Mark-Simulacrum commentedon Sep 3, 2021
This was a regression but is no longer tracked for a particular release.
Auto merge of rust-lang#96576 - oli-obk:post_monomorphization_error_b…
pnkfelix commentedon Dec 16, 2022
Current output as of 1.66:
This seems leaps and bounds better than it was when this was first filed...
pnkfelix commentedon Dec 16, 2022
@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 commentedon Dec 16, 2022
(I suppose at minimum we should add a regression test, to ensure we catch if the output gets worse...)
oli-obk commentedon Dec 16, 2022
Oh yea, this is fixed now
oli-obk commentedon Dec 16, 2022
This was fixed in #104449