Enum rustc_middle::mir::syntax::Operand

pub enum Operand<'tcx> {
    Copy(Place<'tcx>),
    Move(Place<'tcx>),
    Constant(Box<ConstOperand<'tcx>>),
}

An operand in MIR represents a “value” in Rust, the definition of which is undecided and part of the memory model. One proposal for a definition of values can be found on UCG.

The most common way to create values is via loading a place. Loading a place is an operation which reads the memory of the place and converts it to a value. This is a fundamentally typed operation. The nature of the value produced depends on the type of the conversion. Furthermore, there may be other effects: if the type has a validity constraint loading the place might be UB if the validity constraint is not met.

Needs clarification: Is loading a place that has its variant index set well-formed? Miri currently implements it, but it seems like this may be something to check against in the validator.

Variants

Copy(Place<'tcx>)

Creates a value by loading the given place.

Before drop elaboration, the type of the place must be Copy. After drop elaboration there is no such requirement.

Move(Place<'tcx>)

Creates a value by performing loading the place, just like the Copy operand.

This may additionally overwrite the place with uninit bytes, depending on how we decide in UCG#188. You should not emit MIR that may attempt a subsequent second load of this place without first re-initializing it.

Needs clarification: The operational impact of Move is unclear. Currently (both in Miri and codegen) it has no effect at all unless it appears in an argument to Call; for Call it allows the argument to be passed to the callee “in-place”, i.e. the callee might just get a reference to this place instead of a full copy. Miri implements this with a combination of aliasing model “protectors” and putting uninit into the place. Ralf proposes that we don’t want these semantics for Move in regular assignments, because loading a place should not have side-effects, and the aliasing model “protectors” are inherently tied to a function call. Are these the semantics we want for MIR? Is this something we can even decide without knowing more about Rust’s memory model?

Constant(Box<ConstOperand<'tcx>>)

Constants are already semantically values, and remain unchanged.

Implementations

impl<'tcx> Operand<'tcx>

pub fn function_handle( tcx: TyCtxt<'tcx>, def_id: DefId, args: impl IntoIterator<Item = GenericArg<'tcx>>, span: Span, ) -> Self

Convenience helper to make a constant that refers to the fn with given DefId and args. Since this is used to synthesize MIR, assumes user_ty is None.

pub fn is_move(&self) -> bool

pub fn const_from_scalar( tcx: TyCtxt<'tcx>, ty: Ty<'tcx>, val: Scalar, span: Span, ) -> Operand<'tcx>

Convenience helper to make a literal-like constant from a given scalar value. Since this is used to synthesize MIR, assumes user_ty is None.

pub fn to_copy(&self) -> Self

pub fn place(&self) -> Option<Place<'tcx>>

Returns the Place that is the target of this Operand, or None if this Operand is a constant.

pub fn constant(&self) -> Option<&ConstOperand<'tcx>>

Returns the ConstOperand that is the target of this Operand, or None if this Operand is a place.

pub fn const_fn_def(&self) -> Option<(DefId, GenericArgsRef<'tcx>)>

Gets the ty::FnDef from an operand if it’s a constant function item.

While this is unlikely in general, it’s the normal case of what you’ll find as the func in a TerminatorKind::Call.

impl<'tcx> Operand<'tcx>

pub fn ty<D>(&self, local_decls: &D, tcx: TyCtxt<'tcx>) -> Ty<'tcx>

where D: HasLocalDecls<'tcx> + ?Sized,

pub fn span<D>(&self, local_decls: &D) -> Span

where D: HasLocalDecls<'tcx> + ?Sized,

Trait Implementations

impl<'tcx> Clone for Operand<'tcx>

fn clone(&self) -> Operand<'tcx>

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl<'tcx> Debug for Operand<'tcx>

fn fmt(&self, fmt: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'tcx, __D: TyDecoder<I = TyCtxt<'tcx>>> Decodable<__D> for Operand<'tcx>

fn decode(__decoder: &mut __D) -> Self

impl<'tcx, __E: TyEncoder<I = TyCtxt<'tcx>>> Encodable<__E> for Operand<'tcx>

fn encode(&self, __encoder: &mut __E)

impl<'tcx> Hash for Operand<'tcx>

fn hash<__H: Hasher>(&self, state: &mut __H)

Feeds this value into the given Hasher.

fn hash_slice<H>(data: &[Self], state: &mut H)

where H: Hasher, Self: Sized,

Feeds a slice of this type into the given Hasher.

impl<'tcx, '__ctx> HashStable<StableHashingContext<'__ctx>> for Operand<'tcx>

fn hash_stable( &self, __hcx: &mut StableHashingContext<'__ctx>, __hasher: &mut StableHasher, )

impl<'tcx> PartialEq for Operand<'tcx>

fn eq(&self, other: &Operand<'tcx>) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for Operand<'tcx>

fn try_fold_with<__F: FallibleTypeFolder<TyCtxt<'tcx>>>( self, __folder: &mut __F, ) -> Result<Self, __F::Error>

The entry point for folding. To fold a value t with a folder f call: t.try_fold_with(f).

fn fold_with<F>(self, folder: &mut F) -> Self

where F: TypeFolder<I>,

A convenient alternative to try_fold_with for use with infallible folders. Do not override this method, to ensure coherence with try_fold_with.

impl<'tcx> TypeVisitable<TyCtxt<'tcx>> for Operand<'tcx>

fn visit_with<__V: TypeVisitor<TyCtxt<'tcx>>>( &self, __visitor: &mut __V, ) -> __V::Result

The entry point for visiting. To visit a value t with a visitor v call: t.visit_with(v).

impl<'tcx> StructuralPartialEq for Operand<'tcx>

Layout

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.

Size: 24 bytes

Size for each variant:

• Copy: 16 bytes
• Move: 16 bytes
• Constant: 8 bytes