Implement (but don't use) valtree and refactor in preparation of use

[oli-obk]

This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes.

cc @rust-lang/wg-const-eval on the following commits:

• 2027184 implement valtree
• eeecea9 fallible Scalar -> ScalarInt
• 042f663 ScalarInt convenience methods

cc @eddyb on ef04a6d

cc @rust-lang/wg-mir-opt for cf1700c (mir::Constant can now represent either a ConstValue or a ty::Const, and it is totally possible to have two different representations for the same value)

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[lcnr]

why are you using ConstantSource::Ty instead of Val here?

do you prefer ty::Const values over allocations where possible?

[oli-obk]

Mostly in order to change as little as possible. ConstantSource::Val is essentially dead code in this PR

[lcnr]

it's kinda unfortunate that ConstantSource has some duplication between it's variants, changing it to something like

enum ConstantSource {
    Param(ParamConst),
    Bound(...),
    Unevaluated(...),
    Value(...),
    Err(...),
}

would be nice, but it's also a bit annoying because we have to somehow change this for the subst folder to work correctly.
using normalize to evaluate the Unevaluated won't work anyways cause that evaluation might not return something representable as a val tree

probably missed/forgot some previous discussion about this

[bors]

☔ The latest upstream changes (presumably #82953) made this pull request unmergeable. Please resolve the merge conflicts.

[oli-obk]

some duplication between it's variants, changing it to something like

you mean the two occurrences of ConstValue? One of them (the one in ty::Const will become ValTree, but you are right, we will keep having that duplication).

but it's also a bit annoying because we have to somehow change this for the subst folder to work correctly.

Yea, I have a local branch where I tried making ty::Const generic over ValTree or ConstValue to resolve this, but this is way too invasive to do right now. If we do this PR, then we get there in smaller steps. Yes the MIR isn't nice because you have two different representations for the same concrete constant, but the MIR already has that right now (ByRef can technically represent scalars).

The reason this PR is a better first step is that we have to handle all special cases around mir::Constant already without getting the hit on the "make everything generic" solution. Of course we could also "just" have fold_constant in addition to fold_const, but then we'll also get a lot of duplication that I don't know how to handle properly yet (like do we even need Infer, Bound and Param for mir::Constant?). We can explore all these questions with runtime checks before doing the hard thing and cleaning it all up.

[lcnr]

would be r=me

@matthewjasper want to still look over this?

[oli-obk]

@bors r=RalfJung,lcnr,matthewjasper

[bors]

📌 Commit c4d564c has been approved by RalfJung,lcnr,matthewjasper

[bors]

⌛ Testing commit c4d564c with merge e655fb6...

[bors]

☀️ Test successful - checks-actions
Approved by: RalfJung,lcnr,matthewjasper
Pushing e655fb6 to master...

[rylev]

@oli-obk @lcnr This seems to have regressed performance slightly in the ctfe stress benchmarks. The regression seems to happen in the eval_to_allocation_raw query. If this change is purely adding unused code, perhaps some inlining has been impacted in the refactoring?

[oli-obk]

cachegrind diff:

+1,933,323,286  ???:rustc_mir::interpret::operand::<impl rustc_mir::interpret::eval_context::InterpCx<M>>::const_val_to_op
-1,352,146,900  ???:rustc_mir::interpret::operand::<impl rustc_mir::interpret::eval_context::InterpCx<M>>::const_to_op
+452,987,692  ???:rustc_middle::ty::normalize_erasing_regions::<impl rustc_middle::ty::context::TyCtxt>::subst_and_normalize_erasing_regions
+227,857,068  ???:rustc_mir::interpret::operand::<impl rustc_mir::interpret::eval_context::InterpCx<M>>::eval_operand
+158,899,167  ???:rustc_mir::interpret::step::<impl rustc_mir::interpret::eval_context::InterpCx<M>>::run
+155,194,634  ???:<rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::query::TyCtxtAt> as rustc_target::abi::LayoutOf>::layout_of
+17,034,883  ???:<core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold
-14,942,211  ???:<rustc_middle::ty::normalize_erasing_regions::NormalizeAfterErasingRegionsFolder as rustc_middle::ty::fold::TypeFolder>::fold_const
-7,340,200  ???:rustc_middle::mir::interpret::value::ConstValue::try_to_bits
+3,932,250  ???:rustc_middle::mir::interpret::value::ConstValue::try_to_machine_usize