Skip to main content

Module state

Module state 

Source
Expand description

Symbolic VM state types.

The data structures that represent the symbolic execution state: symbolic values and their invariants, memory allocations, and the full execution state at a program point.

StructsΒ§

AllocFacts πŸ”’
Per-allocation lifecycle facts (dead/liveness/for_each), kept apart from the allocation’s shape metadata and parent edge so identity/layout and facts are separated at the type level. The content facts (readability, C-string/UTF-8 trust) live on ContentFacts instead.
AllocId πŸ”’
Unique identifier for a heap or stack allocation.
Allocation πŸ”’
A memory allocation: a stack local, a heap object (Box/Vec), or an external raw-pointer placeholder.
Constraints πŸ”’
Accumulated solver state for the current path.
ContentFacts πŸ”’
Per-allocation content facts: whether the allocation’s contents are readable, and whether they were asserted to be a valid C string / UTF-8. These describe the stored bytes/values, so they live on MemoryContent next to that data, rather than on AllocFacts (lifecycle).
ForEachFacts πŸ”’
Uniform facts about the pointer elements of a container, established by x.iter() for_each invariants.
FrameState πŸ”’
The frame-scoped subset of VmState: the name β†’ allocation binding keyed by MIR Local, which the callee reuses, so it must be swapped out for the duration of an inlined callee and swapped back afterwards.
InlineCtx πŸ”’
Scratch state for the recursive inlined-callee mechanism ([crate::verify::vm::call::exec_inline_call]), which unwinds via the Rust call stack, is bounded by inline_depth, and stashes its per-call bindings in arg_referents/deferred_field_writes.
MemoryContent πŸ”’
The per-allocation contents: the byte layer, the typed-value layer, and the content facts.
MemoryUnit πŸ”’
A single allocation: its shape metadata (Allocation) plus its contents (MemoryContent). Splitting the two keeps the identity/layout facts apart from the mutable memory the values live in, while colocating them in one unit so no parallel table can drift out of sync. Facts live in three anchored layers β€” lifecycle (AllocFacts), content (ContentFacts), and value (ValueFacts on each VmValue) β€” see each type’s doc.
PathFacts πŸ”’
Per-path facts, read afterwards by the property checker.
Provenance πŸ”’
Pointer provenance: which allocation, at what byte offset, and (when known) what structure that offset has.
TermCaches πŸ”’
Term-provenance caches, one per phenomenon the VM must shape by hand.
ValueFacts πŸ”’
Value-level facts about a single symbolic value (nullness, alignment, bounds, and whether it has been written). These travel with the value β€” a VmValue leaves its allocation when passed as an operand or stashed in InlineCtx::deferred_field_writes β€” so they live on the value, not the allocation. The allocation-level counterpart to init is ContentFacts::initialized, kept in sync by VmState::mark_initialized.
VmState πŸ”’
The full symbolic execution state at a program point.
VmValue πŸ”’
A symbolic value tracked by the VM.

EnumsΒ§

AllocKind πŸ”’
The shape of an allocation: a single object, a slice/array buffer, or an external raw-pointer parameter. element_ty (typed vs untyped) and the parent sub-view edge stay separate fields.
ElementTy πŸ”’
The element type of an allocation’s contents, either a concrete [Ty] or symbolic (Generic).
OffsetKind πŸ”’
The structure of a pointer’s byte offset, when it has one.
ValueSource πŸ”’
The extra semantics attached to a value, beyond its term/type/provenance.