Enum rustc_middle::mir::StatementKind

pub enum StatementKind<'tcx> {
    Assign(Box<(Place<'tcx>, Rvalue<'tcx>)>),
    FakeRead(Box<(FakeReadCause, Place<'tcx>)>),
    SetDiscriminant {
        place: Box<Place<'tcx>>,
        variant_index: VariantIdx,
    },
    Deinit(Box<Place<'tcx>>),
    StorageLive(Local),
    StorageDead(Local),
    Retag(RetagKind, Box<Place<'tcx>>),
    AscribeUserType(Box<(Place<'tcx>, UserTypeProjection)>, Variance),
    Coverage(Box<Coverage>),
    CopyNonOverlapping(Box<CopyNonOverlapping<'tcx>>),
    Nop,
}

The various kinds of statements that can appear in MIR.

Not all of these are allowed at every MirPhase. Check the documentation there to see which ones you do not have to worry about. The MIR validator will generally enforce such restrictions, causing an ICE if they are violated.

Variants

Assign(Box<(Place<'tcx>, Rvalue<'tcx>)>)

Assign statements roughly correspond to an assignment in Rust proper (x = ...) except without the possibility of dropping the previous value (that must be done separately, if at all). The exact way this works is undecided. It probably does something like evaluating the LHS to a place and the RHS to a value, and then storing the value to the place. Various parts of this may do type specific things that are more complicated than simply copying bytes.

Needs clarification: The implication of the above idea would be that assignment implies that the resulting value is initialized. I believe we could commit to this separately from committing to whatever part of the memory model we would need to decide on to make the above paragragh precise. Do we want to?

Assignments in which the types of the place and rvalue differ are not well-formed.

Needs clarification: Do we ever want to worry about non-free (in the body) lifetimes for the typing requirement in post drop-elaboration MIR? I think probably not - I’m not sure we could meaningfully require this anyway. How about free lifetimes? Is ignoring this interesting for optimizations? Do we want to allow such optimizations?

Needs clarification: We currently require that the LHS place not overlap with any place read as part of computation of the RHS for some rvalues (generally those not producing primitives). This requirement is under discussion in #68364. As a part of this discussion, it is also unclear in what order the components are evaluated.

See Rvalue documentation for details on each of those.

FakeRead(Box<(FakeReadCause, Place<'tcx>)>)

This represents all the reading that a pattern match may do (e.g., inspecting constants and discriminant values), and the kind of pattern it comes from. This is in order to adapt potential error messages to these specific patterns.

Note that this also is emitted for regular let bindings to ensure that locals that are never accessed still get some sanity checks for, e.g., let x: ! = ..;

When executed at runtime this is a nop.

Disallowed after drop elaboration.

SetDiscriminant

Fields

place: Box<Place<'tcx>>

variant_index: VariantIdx

Write the discriminant for a variant to the enum Place.

This is permitted for both generators and ADTs. This does not necessarily write to the entire place; instead, it writes to the minimum set of bytes as required by the layout for the type.

Deinit(Box<Place<'tcx>>)

Deinitializes the place.

This writes uninit bytes to the entire place.

StorageLive(Local)

StorageLive and StorageDead statements mark the live range of a local.

Using a local before a StorageLive or after a StorageDead is not well-formed. These statements are not required. If the entire MIR body contains no StorageLive/StorageDead statements for a particular local, the local is always considered live.

More precisely, the MIR validator currently does a MaybeStorageLiveLocals analysis to check validity of each use of a local. I believe this is equivalent to requiring for every use of a local, there exist at least one path from the root to that use that contains a StorageLive more recently than a StorageDead.

Needs clarification: Is it permitted to have two StorageLives without an intervening StorageDead? Two StorageDeads without an intervening StorageLive? LLVM says poison, yes. If the answer to any of these is “no,” is breaking that rule UB or is it an error to have a path in the CFG that might do this?

StorageDead(Local)

See StorageLive above.

Retag(RetagKind, Box<Place<'tcx>>)

Retag references in the given place, ensuring they got fresh tags.

This is part of the Stacked Borrows model. These statements are currently only interpreted by miri and only generated when -Z mir-emit-retag is passed. See https://internals.rust-lang.org/t/stacked-borrows-an-aliasing-model-for-rust/8153/ for more details.

For code that is not specific to stacked borrows, you should consider retags to read and modify the place in an opaque way.

AscribeUserType(Box<(Place<'tcx>, UserTypeProjection)>, Variance)

Encodes a user’s type ascription. These need to be preserved intact so that NLL can respect them. For example:

let a: T = y;

The effect of this annotation is to relate the type T_y of the place y to the user-given type T. The effect depends on the specified variance:

• Covariant – requires that T_y <: T
• Contravariant – requires that T_y :> T
• Invariant – requires that T_y == T
• Bivariant – no effect

When executed at runtime this is a nop.

Disallowed after drop elaboration.

Coverage(Box<Coverage>)

Marks the start of a “coverage region”, injected with ‘-Cinstrument-coverage’. A Coverage statement carries metadata about the coverage region, used to inject a coverage map into the binary. If Coverage::kind is a Counter, the statement also generates executable code, to increment a counter variable at runtime, each time the code region is executed.

CopyNonOverlapping(Box<CopyNonOverlapping<'tcx>>)

Denotes a call to the intrinsic function copy_nonoverlapping.

First, all three operands are evaluated. src and dest must each be a reference, pointer, or Box pointing to the same type T. count must evaluate to a usize. Then, src and dest are dereferenced, and count * size_of::<T>() bytes beginning with the first byte of the src place are copied to the continguous range of bytes beginning with the first byte of dest.

Needs clarification: In what order are operands computed and dereferenced? It should probably match the order for assignment, but that is also undecided.

Needs clarification: Is this typed or not, ie is there a typed load and store involved? I vaguely remember Ralf saying somewhere that he thought it should not be.

Nop

No-op. Useful for deleting instructions without affecting statement indices.

Implementations

impl<'tcx> StatementKind<'tcx>

pub fn as_assign_mut(&mut self) -> Option<&mut (Place<'tcx>, Rvalue<'tcx>)>

pub fn as_assign(&self) -> Option<&(Place<'tcx>, Rvalue<'tcx>)>

Trait Implementations

impl<'tcx> Clone for StatementKind<'tcx>

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

Returns a copy of the value.

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

Performs copy-assignment from source.

impl<'tcx> Debug for StatementKind<'tcx>

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

Formats the value using the given formatter.

impl<'tcx, __D: TyDecoder<'tcx>> Decodable<__D> for StatementKind<'tcx>

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

impl<'tcx, __E: TyEncoder<'tcx>> Encodable<__E> for StatementKind<'tcx>

fn encode(&self, __encoder: &mut __E) -> Result<(), <__E as Encoder>::Error>

impl<'tcx> Hash for StatementKind<'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, 

Feeds a slice of this type into the given Hasher.

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

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

impl<'tcx> PartialEq<StatementKind<'tcx>> for StatementKind<'tcx>

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

This method tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &StatementKind<'tcx>) -> bool

This method tests for !=.

impl<'tcx> TypeFoldable<'tcx> for StatementKind<'tcx>

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

Traverses the type in question, typically by calling try_fold_with on each field/element. This is true even for types of interest such as Ty. This should only be called within TypeFolder methods, when non-custom traversals are desired for types of interest.

fn super_visit_with<__F: TypeVisitor<'tcx>>(
    &self,
    __folder: &mut __F
) -> ControlFlow<__F::BreakTy>

Traverses the type in question, typically by calling visit_with on each field/element. This is true even for types of interest such as Ty. This should only be called within TypeVisitor methods, when non-custom traversals are desired for types of interest.

fn try_fold_with<F: FallibleTypeFolder<'tcx>>(
    self,
    folder: &mut F
) -> Result<Self, F::Error>

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

fn fold_with<F: TypeFolder<'tcx, Error = !>>(self, folder: &mut F) -> Self

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

fn super_fold_with<F: TypeFolder<'tcx, Error = !>>(self, folder: &mut F) -> Self

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

fn visit_with<V: TypeVisitor<'tcx>>(
    &self,
    visitor: &mut V
) -> ControlFlow<V::BreakTy>

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

fn has_vars_bound_at_or_above(&self, binder: DebruijnIndex) -> bool

Returns true if self has any late-bound regions that are either bound by binder or bound by some binder outside of binder. If binder is ty::INNERMOST, this indicates whether there are any late-bound regions that appear free.

fn has_vars_bound_above(&self, binder: DebruijnIndex) -> bool

Returns true if this self has any regions that escape binder (and hence are not bound by it).

fn has_escaping_bound_vars(&self) -> bool

fn has_type_flags(&self, flags: TypeFlags) -> bool

fn has_projections(&self) -> bool

fn has_opaque_types(&self) -> bool

fn references_error(&self) -> bool

fn error_reported(&self) -> Option<ErrorGuaranteed>

fn has_param_types_or_consts(&self) -> bool

fn has_infer_regions(&self) -> bool

fn has_infer_types(&self) -> bool

fn has_infer_types_or_consts(&self) -> bool

fn needs_infer(&self) -> bool

fn has_placeholders(&self) -> bool

fn needs_subst(&self) -> bool

fn has_free_regions(&self) -> bool

“Free” regions in this context means that it has any region that is not (a) erased or (b) late-bound.

fn has_erased_regions(&self) -> bool

fn has_erasable_regions(&self) -> bool

True if there are any un-erased free regions.

fn is_global(&self) -> bool

Indicates whether this value references only ‘global’ generic parameters that are the same regardless of what fn we are in. This is used for caching.

fn has_late_bound_regions(&self) -> bool

True if there are any late-bound regions

fn still_further_specializable(&self) -> bool

Indicates whether this value still has parameters/placeholders/inference variables which could be replaced later, in a way that would change the results of impl specialization.

impl<'tcx> StructuralPartialEq for StatementKind<'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: 16 bytes

Size for each variant:

• Assign: 15 bytes
• FakeRead: 15 bytes
• SetDiscriminant: 15 bytes
• Deinit: 15 bytes
• StorageLive: 7 bytes
• StorageDead: 7 bytes
• Retag: 15 bytes
• AscribeUserType: 15 bytes
• Coverage: 15 bytes
• CopyNonOverlapping: 15 bytes
• Nop: 0 bytes