Evaluating constants in MIR optimizations introduces const eval errors

[tmiasko]

#![feature(inline_const)]
#![crate_type = "lib"]
pub fn f<T>() -> usize {
    g::<()>()
}
pub fn g<T>() -> usize {
    const { 0 / std::mem::size_of::<T>() }
}

This compiles fine in debug builds, but fails in release builds:

$ rustc b.rs
$ rustc b.rs -O
error[E0080]: evaluation of `g::<()>::{constant#0}` failed
 --> b.rs:7:13
  |
7 |     const { 0 / std::mem::size_of::<T>() }
  |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to divide `0_usize` by zero

error: aborting due to 1 previous error

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

Based on #107503 (comment) cc @RalfJung.

But also see this example based on type sizes.

[RalfJung]

Ah, so there is a way to trigger this via inlining, dang.

Cc @rust-lang/wg-const-eval @rust-lang/wg-mir-opt

[RalfJung]

All functions in this example are generic, so no amount of collector tweaking can possibly help here.

I don't really see an alternative to developing some sort of const-eval query that suppresses the error.

[RalfJung]

Also, note that even if we get such a "silent const-eval query", all the stuff in #122568 is still needed -- collection definitely wants to use the "loud" const-eval query. That's also what makes #122814 an independent issue from this one, even though both involve "inlining":

• This one here is about the MIR inliner monomorphizing constants, which leads to new const-eval errors.
• The other one is about #[inline] functions being cross-crate-inlinable for LLVM which affects what happens during mono-item collection.

[RalfJung]

So how could such a silent query work? I think we need a query that returns roughly Result<RawConst, ErrorInfo> where ErrorInfo contains everything needed to render the error -- in particular, all the spans of the backtrace. The the query caller can decide whether they want to ignore or show errors. We probably want a 2nd query that shows errors so that we still get deduplication if the constant is eval'd multiple times.

That sounds very doable, though perf may become a problem. What's less clear to me is how to deal with nested queries: evaluating a const may require evaluating other consts; what if those fail? If the innermost const-eval query uses silent queries for nested eval, we'll have to propagate such error info up to the result of the outer query or else we'll never see the inner failures. So probably we want ErrorInfo to be interned such that one ErrorInfo can link to the ErrorInfo of a nested query that failed, or something like that?

[oli-obk]

Sounds like you want what #92674 tried to do. A Reveal mode that silences const eval errors and reruns in an erroring mode if one wants to report an error. So you still get caching in the success case, but need to rerun in the error case.

That was nontrivial to actually do, but I don't remember the issues