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.

[RalfJung]

Things sure have calmed down a bit. You should probably work on top of #55915 though, that one is I think the most conflict-risky.

But we should first assemble a list of renames that we all are happy with. Which renames to you intend to do?

[pvdrz]

Sure, let me check the source code and I'll put a list

[kenta7777]

I'd like to tackle this issue. How shall we begin?

[oli-obk]

As a first step you can look for all uses of EvalContext and rename them to InterpretCx

[kenta7777]

As the next step, should I rename EvalErrorKind to InterpretErrorKind or make a list for renames?

[eddyb]

For errors/results, maybe we can do the io::{Error, Result} thing and have interpret::{Error, Result}?

[Centril]

I think that can turn rather ambiguous and contextual in a large codebase like rustc.

[eddyb]

It bothers me how much shorter Miri is than Interpret.
Maybe IError and IResult?

[Centril]

@eddyb InterpError?

[eddyb]

I have to say that shorter prefixes are ambiguous, and the only other shortenings I can think of involve removing vowels, i.e. IntrptError. Nevermind, "interp" only has one non-leading vowel...
So MiriError or InterpError it is?

[Centril]

It is.

[kenta7777]

Could I rename EvalErrorKind to InterpError?
similary, EvalResult to InterpResult, EvalSnapshot to InterpSnapshot?

[kenta7777]

This is a list for renames.

• EvalErrorKind to InterpError
• EvalResult to InterpResult
• EvalSnapshot to InterpSnapshot