Get the eval out of miri engine

[RalfJung]

I would prefer if this was named ConstEvalInterpreter or ConstEvalMachine to keep in the spirit of const_eval names while removing "eval" from everywhere in the interpret module.

So, in particular, EvalContext should become something else. InterpContext? InterpretContext?

The actual renaming is pretty easy to do, but there is a high change of conflicts with other PRs, so you should arrange the timing with @oli-obk and @RalfJung.

[eddyb]

InterpretCx is probably in the direction we'd want to go.

[Centril]

InterpCtx sounds optimal =P

[csmoe]

I prefer InterpCtxt which is more consistent with TyCtxt for type context.

[Centril]

@csmoe I can agree to the extra 't' =P

[pvdrz]

Hi @RalfJung, I'd like to help in this one to get my feet wet. How/when shall we begin?

[RalfJung]

We currently have #54380 and #53821 in flight and I have https://github.com/RalfJung/rust/tree/pointer-provenance lined up. We should wait for these to land, I think... which could take a bit at the current speed. :/

Until then, you could prepare a list of renames. Is there anything in librustc_mir::interpret that also has "eval" in its name?

[pvdrz]

Well, according to ripgrep we have EvalResult, EvalErrorKind and EvalSnapshot

[RalfJung]

Sounds reasonable. So which new names do we want to pick? s/Eval/Interp/ sounds reasonable?

[pvdrz]

yeah that sounds reasonable

[eddyb]

FWIW the "latest" convention, that I apparently forgot to try and convert the rest of the compiler to, is the Cx suffix for types.

[eddyb]

@christianpoveda I'm not sure we needed the Eval prefix, except for EvalResult - can we do the io::Result thing here?

[pvdrz]

Sure :)

[pvdrz]

@RalfJung are we ready to do this? #54380 and #53821 have been merged.