MIR Constant Values, ValTrees, and Promoted Constants

constants: MIR constants evaluate to a `mir::ConstValue`; type system constants evaluate to a `ty::ValTree`. Type system constants have some more variants to support const generics: they can refer to local const generic parameters, and they are subject to inference. Furthermore, the `mir::Constant::Ty` variant lets us use an arbitrary type system constant as a MIR constant; this happens whenever a const generic parameter is used as an operand. ### MIR constant values In general, a MIR constant value (`mir::ConstValue`) was computed by evaluating some constant the user wrote. This [const evaluation](../const-eval.md) produces a very low-level representation of the result in terms of individual bytes. We call this an "indirect" constant (`mir::ConstValue::Indirect`) since the value is stored in-memory. However, storing everything in-memory would be awfully inefficient. Hence there are some other variants in `mir::ConstValue` that can represent certain simple and common values more efficiently. In particular, everything that can be directly written as a literal in Rust (integers, floats, chars, bools, but also `"string literals"` and `b"byte string literals"`) has an optimized variant that avoids the full overhead of the in-memory representation. ### ValTrees An evaluated type system constant is a "valtree". The `ty::ValTree` datastructure allows us to represent * arrays, * many structs, * tuples, * enums and, * most primitives. The most important rule for this representation is that every value must be uniquely represented. In other words: a specific value must only be representable in one specific way. For example: there is only one way to represent an array of two integers as a `ValTree`: `Branch([Leaf(first_int), Leaf(second_int)])`. Even though theoretically a `[u32; 2]` could be encoded in a `u64` and thus just be a `Leaf(bits_of_two_u32)`, that is not a legal construction of `ValTree` (and is very complex to do, so it is unlikely anyone is tempted to do so). These rules also mean that some values are not representable. There can be no `union`s in type level constants, as it is not clear how they should be represented, because their active variant is unknown. Similarly there is no way to represent raw pointers, as addresses are unknown at compile-time and thus we cannot make any assumptions about them. References on the other hand *can* be represented, as equality for references is defined as equality on their value, so we ignore their address and just look at the backing value. We must make sure that the pointer values of the references are not observable at compile time. We thus encode `&42` exactly like `42`. Any conversion from valtree back to a MIR constant value must reintroduce an actual indirection. At codegen time the addresses may be deduplicated between multiple uses or not, entirely depending on arbitrary optimization choices. As a consequence, all decoding of `ValTree` must happen by matching on the type first and making decisions depending on that. The value itself gives no useful information without the type that belongs to it. <a id="promoted"></a> ### Promoted constants See the const-eval WG's [docs on promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md).

MIR constant values (`mir::ConstValue`) are low-level byte representations of constants. To avoid inefficiency, simple values like literals (integers, floats, strings, etc.) have optimized variants in `mir::ConstValue` that avoid full in-memory overhead. Type system constants can be represented by `ty::ValTree`. `ValTree` allows for representation of arrays, structs, tuples, enums and primitives. Every value must be uniquely represented. Values that cannot be uniquely represented, such as unions and raw pointers, are not representable in `ValTree`. References are represented by their value, and their address is ignored. Conversion from `ValTree` back to a MIR constant must reintroduce an indirection. Decoding `ValTree` requires matching on the type first. Promoted constants are covered in the const-eval WG's documentation.