Split ConstValue

[RalfJung]

The ConstValue type serves different purposes currently. As return value of const_eval for statics, consts and promoteds, we could instead always return an AllocId + offset (i.e., a Pointer) and avoid even thinking about whether we want the value to be immediate instead. Some places want an immediate (array lengths, pattern matching), they could get a different query returning a different type that "wraps" the main query.

So, I imagine something like: We have one type that serves the current role of ConstValue

enum Const<'tcx> {
   Unevaluated(DefId, &'tcx Substs<'tcx>),
   Evaluated(Pointer),
}

and a new one

enum ConstValue {
  Scalar(Scalar),
  ScalarPair(Scalar, Scalar),
}

(I called the latter ConstValue for symmetry with the Value type. But maybe it's better to not change too many names, and call the 2nd type ConstImmediate or so.)

Then we make the const_eval query return a Pointer, and we add a new query const_eval_value returning a ConstValue.

Overall, this uses the type system to encode that the queries never return Unevaluated, and it lets most callers handle everything uniformly (no need to deal with immediates unless needed).

Cc @oli-obk @eddyb -- does this make any sense?

[RalfJung]

Actually, the function producing an immediate doesn't even have to be a query. It could just be a convenience function provided by tcx or const_eval.

[oli-obk]

does this make any sense?

yes. I think we talked about this before and I'm still very much in favour.

[eddyb]

This seems potentially slow, I'd like to get const generics and lazy normalization first, then we can see if we can do this efficiently - I suspect so, but I'm not sure exactly what we'd need.

[RalfJung]

What do you think is slow about this?

[eddyb]

@RalfJung I mean, getting the actual value would take an extra operation, but I suppose we can rely on the query being "fast enough" for this to not matter at all.

[oli-obk]

Usually we only need that value once or twice. Extracting the value from the memory is just a few instructions.

At this point we don't even need an (AllocId, Offset) but can use an (&'tcx Allocation, Offset) directly.

[RalfJung]

At this point we don't even need an (AllocId, Offset) but can use an (&'tcx Allocation, Offset) directly.

No, miri engine needs the AllocId here. I added it because of that. IIRC you r+'d that PR. ;)

[oli-obk]

Well, yes XD, then we can do (AllocId, &'tcx Allocation, Offset) like currently.

[oli-obk]

closing in favour of #59210