opportunistically evaluate constants while populating mir::Body::required_consts

[oli-obk]

We can evaluate all constants that do not depend on generic parameters in

rust/src/librustc_mir/transform/required_consts.rs

Line 19 in 0b95879

if let ConstKind::Unevaluated(_, _, _) = const_kind {

We make that a MutVisitor that evaluates all constants that it can and replaces them in-place and only adds those that it couldn't evaluate to the required_const list.

This way we never have to evaluate another constant in the entire MIR optimization pipeline, because we know none can be evaluated (modulo those that we already evaluate for merging required_consts during inlining.

cc @rust-lang/wg-mir-opt I think I like having the above invariant. It will make working with constants in MIR much simpler and make any kind of error handling that would have to be implemented unified into a single location.

[RalfJung]

and make any kind of error handling that would have to be implemented unified into a single location.

Ideally that would actually dispatch through the const_eval error handling to have it all centralized there...

Same goes for the const error reporting that codegen is doing, FWIW.

Which makes me wonder, can we move this impl block to librustc_mir/const_eval/error.rs or so? This is solely CTFE error logic, so logically part of the "CTFE <-> rustc glue" that we otherwise have in librustc_mir::const_eval.

[oli-obk]

hmm right, I think nothing from librustc uses this anymore. We can't move the impl block, but we can make the functions free functions.

[RalfJung]

Yeah something like that.

So we also use this issue to track cleaning up the error reporting story more generally? If we also include cleaning up this then I think we can close #67191, AFAIK that's all that's left.

[RalfJung]

rust-lang/miri#1382 is also related, this is Miri lacking the code that codegen has to properly report post-monomorphization errors.

[RalfJung]

I realized that the cleanup here is not actually made easier by opportunistically evaluating things, because promoteds can still fail to evaluate later. Thus I moved the cleanup to a separate issue: #75461.

[tmiasko]

Evaluating and replacing constants in MIR before promotion interacts with const qualification. Evaluated constants are currently qualified based solely on their type, which is less precise than value based analysis that might be used otherwise. For example, promotion fails for X when it is evaluated in main (type contains interior mutability):

use std::cell::Cell;
const X: Option<Cell<i32>> = None;
fn main() {
    let x: &'static _ = &X;
}

[oli-obk]

Your example already compiles. We compute the qualification for every constant based on its body and then use that cached qualification to decide whether to promote references to it. Unless the unevaluated constant is too generic to get its true body (for associated consts of generic parameters), then we indeed just look at the type.

[tmiasko]

Evaluated constants are treated as opaque so the example stops to compile. This seems almost contradictory that we perform value based analysis only when we don't know the precise value yet.

[oli-obk]

Oh wow. Now I get what you mean. Yea... I see how that would be problematic