Closed Herschel closed 1 year ago
Possibly a regression as a result of the stdarch PR landing, tagging as such so we eventually investigate.
cc @rust-lang/wg-const-eval
I've tried bisecting this error, seems to point out to PR https://github.com/rust-lang/rust/pull/83278
searched nightlies: from nightly-2021-04-01 to nightly-2021-05-11 regressed nightly: nightly-2021-05-09 searched commits: from https://github.com/rust-lang/rust/commit/770792ff8d1ec542e78e77876ac936f43ffb8e05 to https://github.com/rust-lang/rust/commit/881c1ac408d93bb7adaa3a51dabab9266e82eee8 regressed commit: https://github.com/rust-lang/rust/commit/881c1ac408d93bb7adaa3a51dabab9266e82eee8
Oh wow, that is the error when run with miri. The error in regular builds has no information beyond "const eval failed"
Ah, this is a post-monomorphization error. This is already being tracked in https://github.com/rust-lang/rust/issues/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.
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.
@rustbot label -I-prioritize +P-high
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).
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
I'd be happy to mentor someone who wants to implement that
@oli-obk I would like to help :)
re https://github.com/rust-lang/rust/issues/85155#issuecomment-840715762: I think that would require evaluating the required consts of a MIR body inside the mono item collector.
This was a regression but is no longer tracked for a particular release.
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...
@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?)
(I suppose at minimum we should add a regression test, to ensure we catch if the output gets worse...)
Oh yea, this is fixed now
This was fixed in https://github.com/rust-lang/rust/pull/104449
Given the following code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=0a24628f94a07753519f86993f792ddb
The current output is:
Pointing to these lines inside
std::arch
: https://github.com/rust-lang/stdarch/blob/master/crates/core_arch/src/macros.rs#L5-L10The 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 forarch::
and lots of trial and error. Neither--verbose
norRUST_BACKTRACE
were helpful. Someone later mentioned thatRUSTC_LOG=rustc_mir::interpret=info
could help track it down, but this is user-unfriendly.Impacting this issue in the wild: https://github.com/ejmahler/RustFFT/issues/74 https://github.com/rust-lang/stdarch/issues/1159