Trait rustc_const_eval::interpret::visitor::ValueMut

source · [−]
pub trait ValueMut<'mir, 'tcx, M: Machine<'mir, 'tcx>>: Sized {
    fn layout(&self) -> TyAndLayout<'tcx>;
    fn to_op_for_read(
        &self,
        ecx: &InterpCx<'mir, 'tcx, M>
    ) -> InterpResult<'tcx, OpTy<'tcx, M::Provenance>>;
    fn to_op_for_proj(
        &self,
        ecx: &mut InterpCx<'mir, 'tcx, M>
    ) -> InterpResult<'tcx, OpTy<'tcx, M::Provenance>>;
    fn from_op(op: &OpTy<'tcx, M::Provenance>) -> Self;
    fn project_downcast(
        &self,
        ecx: &mut InterpCx<'mir, 'tcx, M>,
        variant: VariantIdx
    ) -> InterpResult<'tcx, Self>;
    fn project_field(
        &self,
        ecx: &mut InterpCx<'mir, 'tcx, M>,
        field: usize
    ) -> InterpResult<'tcx, Self>;
}
Expand description

A thing that we can project into given mutable access to ecx, and that has a layout. This wouldn’t have to depend on Machine but with the current type inference, that’s just more convenient to work with (avoids repeating all the Machine bounds).

Required Methods

Gets this value’s layout.

Makes this into an OpTy, in a cheap way that is good for reading.

Makes this into an OpTy, in a potentially more expensive way that is good for projections.

Creates this from an OpTy.

If to_op_for_proj only ever produces Indirect operands, then this one is definitely Indirect.

Projects to the given enum variant.

Projects to the n-th field.

Implementors