After #149114 ValTree's Branches variant stores a list of ty::Const instead of a list of ValTrees. See the PR description and associated zulip thread (#project-const-generics > Valtrees that can contain generic params) for a motivation for this.
This has left us with two problems:
- The name
Value is kinda confusing :) These are in some sense not full values. It may be desirable to rename ConstKind::Value, ty::Value, ty::ValTree and ty::ValTreeKind to something different now that they don't represent full values.
- There are now a bunch of extra
Ty in a fully evaluate ValTree. This is likely bad for performance. Though more importantly it means that when CTFE evaluates something to a ValTree it has to pick types for all the nested nodes in a ValTree. This is effectively impossible for CTFE to do correctly as it doesn't have lifetime information so we wind up with a bunch of erased lifetimes entering the type system.
The second point can be observed by looking at debug logs for this code example:
#![feature(adt_const_params, unsized_const_params)]
#![expect(incomplete_features)]
#![crate_type = "lib"]
struct Foo<'a> {
r: &'a u32,
}
fn bar<const N: Foo<'static>>() { }
fn qux() {
bar::<{ Foo { r: &1 } }>();
}
0ms DEBUG rustc_trait_selection::traits ct=UnevaluatedConst { def: DefId(0:9 ~ foo[cae9]::qux::{constant#0}), args: [] }
0ms DEBUG rustc_trait_selection::traits return=Ok(ValTree(Branch([ValTree(Leaf(0x00000001): &'{erased} u32)]): Foo::<'static>))
Assigning myself as I'm partially through fixing this second point.
After #149114
ValTree'sBranchesvariant stores a list ofty::Constinstead of a list ofValTrees. See the PR description and associated zulip thread (#project-const-generics > Valtrees that can contain generic params) for a motivation for this.This has left us with two problems:
Valueis kinda confusing :) These are in some sense not full values. It may be desirable to renameConstKind::Value,ty::Value,ty::ValTreeandty::ValTreeKindto something different now that they don't represent full values.Tyin a fully evaluateValTree. This is likely bad for performance. Though more importantly it means that when CTFE evaluates something to aValTreeit has to pick types for all the nested nodes in aValTree. This is effectively impossible for CTFE to do correctly as it doesn't have lifetime information so we wind up with a bunch of erased lifetimes entering the type system.The second point can be observed by looking at debug logs for this code example:
Assigning myself as I'm partially through fixing this second point.