Mir on Opensource internals

Four Ways to Drop: How rustc Decides Whether a Value Needs a Drop Flag

Jay Hubbert — Wed, 21 Oct 2026 11:15:00 +0000

TL;DR: Every Drop terminator in MIR becomes a guarded drop. rustc classifies each one into four cases — Dead (never drop), Static (always drop), Conditional (depends on a runtime flag) and Open (drop the fields separately) — using two dataflow analyses. Only the Conditional case allocates a flag, so a local that is definitely moved out generates no drop code at all.

Rust’s drop semantics are subtle. A local may be moved out before the end of its scope, in which case it must not be dropped. It may be moved out on some paths but not others, in which case a runtime flag is needed. Or it may be partially moved, in which case only the remaining fields should be dropped.

rustc’s ElaborateDrops pass turns all of this into MIR.

The four-way classification

 rust
 
 
// compiler/rustc_mir_transform/src/elaborate_drop.rs:19-38

/// Describes how/if a value should be dropped.
#[derive(Debug)]
pub(crate) enum DropStyle {
 /// The value is already dead at the drop location, no drop will be executed.
 Dead,

 /// The value is known to always be initialized at the drop location, drop will always be
 /// executed.
 Static,

 /// Whether the value needs to be dropped depends on its drop flag.
 Conditional,

 /// An "open" drop is one where only the fields of a value are dropped.
 ///
 /// For example, this happens when moving out of a struct field: The rest of the struct will be
 /// dropped in such an "open" drop. It is also used to generate drop glue for the individual
 /// components of a value, for example for dropping array elements.
 Open,
}

And the function that decides:

 rust
 
 
// compiler/rustc_mir_transform/src/elaborate_drops.rs:166-190

#[instrument(level = "debug", skip(self), ret)]
fn drop_style(&self, path: Self::Path, mode: DropFlagMode) -> DropStyle {
 let ((maybe_init, maybe_uninit), multipart) = match mode {
 DropFlagMode::Shallow => (self.init_data.maybe_init_uninit(path), false),
 DropFlagMode::Deep => {
 let mut some_maybe_init = false;
 let mut some_maybe_uninit = false;
 let mut children_count = 0;
 on_all_children_bits(self.move_data(), path, |child| {
 let (maybe_init, maybe_uninit) = self.init_data.maybe_init_uninit(child);
 debug!("elaborate_drop: state({:?}) = {:?}", child, (maybe_init, maybe_uninit));
 some_maybe_init |= maybe_init;
 some_maybe_uninit |= maybe_uninit;
 children_count += 1;
 });
 ((some_maybe_init, some_maybe_uninit), children_count != 1)
 }
 };
 match (maybe_init, maybe_uninit, multipart) {
 (false, _, _) => DropStyle::Dead,
 (true, false, _) => DropStyle::Static,
 (true, true, false) => DropStyle::Conditional,
 (true, true, true) => DropStyle::Open,
 }
}

Read the inputs: maybe_init and maybe_uninit come from two dataflow analyses (MaybeInitializedPlaces and MaybeUninitializedPlaces) that already exist for the borrow checker. multipart says “this value has more than one child move-path”.

The four outcomes:

maybe_init == false → the value is definitely uninitialized at the drop point → Dead. The drop terminator is replaced with a plain goto. No code at all.
maybe_init && !maybe_uninit → definitely initialized → Static. Drop unconditionally, no flag.
maybe_init && maybe_uninit && !multipart → Conditional. Needs a runtime bool flag.
multipart → Open. The drop is decomposed into per-field drops (a “drop ladder”), because a single flag cannot represent “some fields initialized, some not”.

The shallow/deep split

rust

// compiler/rustc_mir_transform/src/elaborate_drop.rs:40-47

DropFlagMode::Shallow looks only at the top-level path — “is this whole value initialized?”. DropFlagMode::Deep aggregates over all children and additionally records whether the path is multipart.

The children_count != 1 test is subtle: it distinguishes “a value with one child that is itself multipart” from “a genuinely multi-field value”. The first case can still use a single flag (the child’s own flag suffices); the second cannot.

Flags are created lazily, and only where needed

 rust
 
 
// compiler/rustc_mir_transform/src/elaborate_drops.rs:292-336

fn collect_drop_flags(&mut self) {
 for (bb, data) in self.body.basic_blocks.iter_enumerated() {
 let terminator = data.terminator();
 let TerminatorKind::Drop { ref place, .. } = terminator.kind else { continue };

 let path = self.move_data().rev_lookup.find(place.as_ref());
 debug!("collect_drop_flags: {:?}, place {:?} ({:?})", bb, place, path);

 match path {
 LookupResult::Exact(path) => {
 self.init_data.seek_before(self.body.terminator_loc(bb));
 on_all_children_bits(self.move_data(), path, |child| {
 let (maybe_init, maybe_uninit) = self.init_data.maybe_init_uninit(child);
 ...
 if maybe_init && maybe_uninit {
 self.create_drop_flag(child, terminator.source_info.span)
 }
 });

The condition for creating a flag is maybe_init && maybe_uninit — that is, exactly the Conditional case. A local that is definitely moved out gets no flag, no alloca, no store, no load, no branch.

What the naive design costs

The traditional approach — which rustc itself used to have — is: every droppable local gets a bool flag, initialised to true, cleared when the value is moved. That costs, per droppable local:

one stack slot,
one store at initialisation,
one store at each move,
one load and one branch at the drop site.

Even for a local whose drop is statically known to be dead, even for a local that is never moved at all.

The 4-way classification reduces the common cases to zero extra instructions. The cost is the two dataflow analyses and the move-path machinery — but those are shared with the borrow checker, so the marginal cost of the whole ElaborateDrops pass is much lower than it looks.

The composite analysis

One more piece of design worth stealing: borrow checking is not one analysis with a three-part domain. It is three analyses composed:

 rust
 
 
// compiler/rustc_borrowck/src/dataflow.rs:15-23

// This analysis is different to most others. Its results aren't computed with
// `iterate_to_fixpoint`, but are instead composed from the results of three sub-analyses that are
// computed individually with `iterate_to_fixpoint`. Because it's faster that way than having a
// single analysis where the domain has three components.
pub(crate) struct Borrowck<'a, 'tcx> {
 pub(crate) borrows: Borrows<'a, 'tcx>,
 pub(crate) uninits: MaybeUninitializedPlaces<'a, 'tcx>,
 pub(crate) ever_inits: EverInitializedPlaces<'a, 'tcx>,
}

Three independent fixpoints beat one fixpoint over a tuple domain, because the tuple’s join would have to merge all three components on every propagation even when only one of them changed.

Where it lives

compiler/rustc_mir_transform/src/elaborate_drop.rs — DropStyle.
compiler/rustc_mir_transform/src/elaborate_drops.rs — drop_style, collect_drop_flags.
compiler/rustc_mir_transform/src/impls/initialized.rs — the MaybeInitializedPlaces analysis.
compiler/rustc_borrowck/src/dataflow.rs — the composed borrowck result.

Takeaway

A boolean flag is a great abstraction and a terrible default. The interesting engineering is in deciding when you need one. rustc answers that question with existing dataflow results rather than with a fresh analysis, and classifies the answer into four cases so that the two statically-decidable ones cost nothing at all.

The Call Graph From the Wrong MIR: How rustc's Inliner Avoids a Query Cycle

Jay Hubbert — Wed, 21 Oct 2026 11:10:00 +0000

TL;DR: Before inlining, rustc asks “could inlining this callee create a query cycle?”. To answer it needs a call graph — but computing the call graph from optimized MIR would itself be a query cycle. So the inliner computes it from mir_promoted, the pre-optimization MIR, which sits lower in the query DAG. The answer is conservative (it may see calls that optimization later removes) but it never deadlocks.

The problem

rustc’s query system is a DAG. optimized_mir(F) depends on optimized_mir(G) for every G that F calls, because the inliner may inline G into F. But that inlining decision depends on knowing the call graph, which is derived from the MIR…

So: to decide whether to inline G into F, the inliner wants to know whether G (transitively) calls F. If it does, inlining G into F would create a query cycle, and the query system would report a cycle error rather than a compile.

The naive implementation — compute the call graph from optimized_mir — builds exactly the cycle it is trying to avoid:

text

optimized_mir(F)
 -> inline(F)
 -> mir_inliner_callees(F)
 -> optimized_mir(G)
 -> inline(G)
 -> ...

The fix: use an earlier MIR

 rust
 
 
// compiler/rustc_mir_transform/src/inline/cycle.rs:192-229

pub(crate) fn mir_inliner_callees<'tcx>(
 tcx: TyCtxt<'tcx>,
 instance: ty::InstanceKind<'tcx>,
) -> &'tcx [(DefId, GenericArgsRef<'tcx>)] {
 let steal;
 let guard;
 let body = match (instance, instance.def_id().as_local()) {
 (InstanceKind::Item(_), Some(def_id)) => {
 steal = tcx.mir_promoted(def_id).0;
 guard = steal.borrow();
 &*guard
 }
 // Functions from other crates and MIR shims
 _ => tcx.instance_mir(instance),
 };
 let mut calls = FxIndexSet::default();
 for bb_data in body.basic_blocks.iter() {
 let terminator = bb_data.terminator();
 let TerminatorKind::Call { func, args: call_args, .. } = &terminator.kind {
 let ty = func.ty(&body.local_decls, tcx);
 let ty::FnDef(def_id, generic_args) = ty.kind() else {
 continue;
 };
 let call = if tcx.is_intrinsic(*def_id, sym::const_eval_select) {
 // `const_eval_select` takes the real callee as an argument.
 let func = &call_args[2].node;
 let ty = func.ty(&body.local_decls, tcx);
 let ty::FnDef(def_id, generic_args) = ty.kind() else {
 continue;
 };
 (*def_id, *generic_args)
 } else {
 (*def_id, *generic_args)
 };
 calls.insert(call);
 }
 }
 tcx.arena.alloc_from_iter(calls.iter().map(|(did, args)| (did, args.no_bound_vars().unwrap())))
}

Two details:

The MIR source is mir_promoted — the MIR before optimization, before inlining, before constant propagation. It sits lower in the query DAG, so asking for it cannot create a cycle.
The const_eval_select special case. That intrinsic takes the real callee as an argument, so a naive scan of call terminators would miss the edge. The code digs into call_args[2] to find it.

The trade-off, stated plainly

The call graph computed from mir_promoted is a superset of the real call graph: optimization might remove a call entirely (a Call to a function whose result is unused and which has no side effects can be deleted), but mir_promoted still shows it.

That means rustc will sometimes refuse to inline something it could have inlined. The trade is deliberate: a conservative refusal costs a little optimization; a cycle costs a failed compile with a confusing error.

How the answer is used

 rust
 
 
// compiler/rustc_mir_transform/src/inline.rs:776-788

if let Some(callee_def_id) = callee_def_id.as_local()
 && !inliner.tcx().is_lang_item(inliner.tcx().parent(caller_def_id), LangItem::FnOnce)
{
 // If we know for sure that the function we're calling will itself try to
 // call us, then we avoid inlining that function.
 let Some(cyclic_callees) = inliner.tcx().mir_callgraph_cyclic(caller_def_id.expect_local())
 else {
 return Err("call graph cycle detection bailed due to recursion limit");
 };
 if cyclic_callees.contains(&callee_def_id) {
 debug!("query cycle avoidance");
 return Err("caller might be reachable from callee");
 }

mir_callgraph_cyclic is a query, so the answer is memoized per function and shared across the whole compilation.

The recursion limit hack, with the best comment in the file

 rust
 
 
// compiler/rustc_mir_transform/src/inline/cycle.rs:161-168

// FIXME(-Znext-solver=no): Remove this hack when trait solver overflow can return an error.
// In code like that pointed out in #128887, the type complexity we ask the solver to deal with
// grows as we recurse into the call graph. If we use the same recursion limit here and in the
// solver, the solver hits the limit first and emits a fatal error. But if we use a reduced
// limit, we will hit the limit first and give up on looking for inlining. And in any case,
// the default recursion limits are quite generous for us. If we need to recurse 64 times
// into the call graph, we're probably not going to find any useful MIR inlining.
let recursion_limit = tcx.recursion_limit() / 8;

This is a genuinely instructive pattern: the cheap analysis should fail before the expensive one. The trait solver’s recursion limit and the call-graph walker’s recursion limit are the same number, and both can be hit by the same pathological code. If the call-graph walker used the same limit, it would hit the limit at the same time as the solver, and the solver’s failure would be a hard error. By using an eighth of the limit, the call-graph walker gives up first, inlining is simply not attempted, and the compile succeeds with slightly worse code.

The other anti-explosion machinery

While we are in the inliner, the other protections are worth mentioning:

 rust
 
 
// compiler/rustc_mir_transform/src/inline.rs:30-31
const HISTORY_DEPTH_LIMIT: usize = 20;
const TOP_DOWN_DEPTH_LIMIT: usize = 5;

history is a stack of DefIds (not full instances). Because the number of DefIds is finite, checking “have I already inlined this function” is enough to break cycles — and it deliberately still allows polymorphic recursion (f::<u8> calling f::<u32>) to be inlined.
top_down_counter caps how many multi-call sites are inlined at the top level, bounding super-linear MIR growth.

And the cost model itself:

 rust
 
 
// compiler/rustc_mir_transform/src/inline.rs:364-381

let mut threshold = if self.caller_is_inline_forwarder || self.past_depth_limit() {
 tcx.sess.opts.unstable_opts.inline_mir_forwarder_threshold.unwrap_or(30)
} else if tcx.cross_crate_inlinable(callsite.callee.def_id()) {
 tcx.sess.opts.unstable_opts.inline_mir_hint_threshold.unwrap_or(100)
} else {
 tcx.sess.opts.unstable_opts.inline_mir_threshold.unwrap_or(50)
};

// Give a bonus functions with a small number of blocks,
// We normally have two or three blocks for even
// very small functions.
if callee_body.basic_blocks.len() <= 3 {
 threshold += threshold / 4;
}

The 25% bonus for small bodies is a heuristic about fixed overhead: even a tiny function has two or three basic blocks, and the per-block cost dominates the per-statement cost.

Where it lives

compiler/rustc_mir_transform/src/inline/cycle.rs — mir_inliner_callees, mir_callgraph_cyclic, the /8 recursion limit.
compiler/rustc_mir_transform/src/inline.rs — the cycle-avoidance check and the cost thresholds.
compiler/rustc_mir_transform/src/inline/cost_checker.rs — the cost model.

Takeaway

When a system with a dependency DAG needs to ask a question about that DAG while computing it, you have to answer the question from a different, earlier version of the data. Here that is “the MIR before we optimized it”. The result is conservative, and the comment in the code says so — but a conservative answer that never deadlocks beats a precise answer that sometimes hangs the compiler.

Why rustc's GVN Refuses to Merge Two Borrows: Provenance as a Type

Jay Hubbert — Wed, 21 Oct 2026 11:05:00 +0000

TL;DR: rustc’s global value numbering (GVN) hash-conses rvalues into value numbers, so two structurally identical &mut x expressions would normally get the same number — and then one would be replaced by the other, which is a miscompile. rustc prevents this by attaching a VnOpaque marker to every pointer value, whose Hash and PartialEq implementations are unreachable!(). The mistake is not “unlikely”, it is impossible.

GVN (global value numbering) is a MIR optimization that finds redundant computations. It works by turning each rvalue into a Value, interning equal values into the same index, and then replacing a use with an earlier definition when that definition dominates the use.

 rust
 
 
// compiler/rustc_mir_transform/src/gvn.rs:286-306

/// Stores and deduplicates pairs of `(Value, Ty)` into in `VnIndex` numbered values.
///
/// This data structure is mostly a partial reimplementation of `FxIndexMap<VnIndex, (Value, Ty)>`.
/// We do not use a regular `FxIndexMap` to skip hashing values that are unique by construction,
/// like opaque values, address with provenance and non-deterministic constants.
struct ValueSet<'a, 'tcx> {
 indices: HashTable<VnIndex>,
 hashes: IndexVec<VnIndex, u64>,
 values: IndexVec<VnIndex, Value<'a, 'tcx>>,
 types: IndexVec<VnIndex, Ty<'tcx>>,
}

Notice the comment: values that are “unique by construction” are not hashed. The ValueSet has an insert_unique path for those, which pushes a new index without ever consulting the hash table.

The problem GVN must not have

Consider:

text

_x = &_a;
 _a = 0;
_y = &_a; // cannot be turned into `_y = _x`!

The two &_a rvalues are structurally identical. A naive GVN would give them the same value number and rewrite _y = &_a into _y = _x. But between the two borrows, _a was overwritten — so _x and _y point at different things (in the aliasing model, _x refers to the old value of _a). Rewriting would be a miscompile and, under Stacked Borrows, a soundness violation.

The fix could be to include the borrow site in the value. But that is not enough: two borrows from the same site at different times are still different values.

The fix: a marker type that cannot be compared

rustc’s solution is a dedicated marker type:

 rust
 
 
// compiler/rustc_mir_transform/src/gvn.rs:196-212

/// Marker type to forbid hashing and comparing opaque values.
/// This struct should only be constructed by `ValueSet::insert_unique` to ensure we use that
/// method to create non-unifiable values. It will ICE if used in `ValueSet::insert`.
#[derive(Copy, Clone, Debug, Eq)]
struct VnOpaque;
impl PartialEq for VnOpaque {
 fn eq(&self, _: &VnOpaque) -> bool {
 // ICE if we try to compare unique values
 unreachable!()
 }
}
impl Hash for VnOpaque {
 fn hash<T: Hasher>(&self, _: &mut Hasher) {
 // ICE if we try to hash unique values
 unreachable!()
 }
}

This is a lovely piece of API design. VnOpaque is embedded in the pointer value:

 rust
 
 
// compiler/rustc_mir_transform/src/gvn.rs:259-268

/// The address of a place.
Address {
 base: AddressBase,
 // We do not use a plain `Place` as we want to be able to reason about indices.
 // This does not contain any `Deref` projection.
 projection: &'a [ProjectionElem<VnIndex, Ty<'tcx>>],
 kind: AddressKind,
 /// Give each borrow and pointer a different provenance, so we don't merge them.
 provenance: VnOpaque,
},

Because VnOpaque implements Eq but its PartialEq::eq is unreachable!(), any code path that tries to compare two pointer values would panic — in debug builds at least, and in release builds it is unreachable!() which LLVM compiles to unreachable (undefined behaviour) or a trap depending on the panic strategy.

The safety comes from the invariant that pointer values are only ever inserted through insert_unique:

rust

// compiler/rustc_mir_transform/src/gvn.rs:308-330

which pushes a fresh index without consulting the hash table at all. Two borrows therefore always get different VnIndexes, and the comparison path is never reached.

This is the “make the illegal state unrepresentable” principle applied to an optimization bug class. The alternative — a disambiguator: u32 field that gets hashed — works too, but it is merely unlikely to be wrong; VnOpaque makes it impossible.

But the pointee is still tracked

The trick does not throw away information. The place being borrowed is still part of the value, so GVN can still reason about *&_a:

 rust
 
 
// compiler/rustc_mir_transform/src/gvn.rs:482-517

fn new_pointer(&mut self, place: Place<'tcx>, kind: AddressKind) -> Option<VnIndex> {
 ...
 let mut projection = place.projection.iter();
 let base = if place.is_indirect_first_projection() {
 let base = self.locals[place.local]?;
 // Skip the initial `Deref`.
 projection.next();
 AddressBase::Deref(base)
 } else if self.ssa.is_ssa(place.local) {
 // Only propagate the pointer of the SSA local.
 AddressBase::Local(place.local)
 } else {
 return None;
 };

So the value is “the address of local 3’s field 1, with fresh provenance”. Two such values are never equal, but GVN still knows what they point at, which lets it rewrite *&x into x when appropriate.

Constants have the same problem, for a different reason

Not all constants are interchangeable either. A Const::Ty (a valtree) can synthesize a fresh allocation each time it is instantiated, so two uses of the same valtree constant may be different pointers:

 rust
 
 
// compiler/rustc_mir_transform/src/gvn.rs:1860-1886

/// Return true if any evaluation of this constant in the same MIR body
/// always returns the same value, taking into account even pointer identity tests.
///
/// In other words, this answers: is "cloning" the `Const` ok?
///
/// This returns `false` for constants that synthesize new allocations when they are instantiated.
/// It is `true` for anything else, since a given `AllocId` *does* have a unique runtime value
/// within the scope of a single MIR body.
fn is_deterministic(c: Const<'_>) -> bool {
 // Primitive types cannot contain provenance and always have the same value.
 if c.ty().is_primitive() {
 return true;
 }

 match c {
 // Some constants may generate fresh allocations for pointers they contain,
 // so using the same constant twice can yield two different results.
 // Notably, valtrees purposefully generate new allocations.
 Const::Ty(..) => false,
 // We do not know the contents, so don't attempt to do anything clever.
 Const::Unevaluated(..) => false,
 // When an evaluated constant contains provenance, it is encoded as an `AllocId`.
 // Cloning the constant will reuse the same `AllocId`. If this is in the same MIR
 // body, this same `AllocId` will result in the same pointer in codegen.
 Const::Val(..) => true,
 }
}

and the insertion path branches on it:

 rust
 
 
// compiler/rustc_mir_transform/src/gvn.rs:519-533

fn insert_constant(&mut self, value: Const<'tcx>) -> VnIndex {
 if is_deterministic(value) {
 // The constant is deterministic, no need to disambiguate.
 let constant = Value::Constant { value, disambiguator: None };
 self.insert(value.ty(), constant)
 } else {
 // Multiple mentions of this constant will yield different values,
 // so assign a different `disambiguator` to ensure they do not get the same `VnIndex`.
 self.insert_unique(value.ty(), |disambiguator| Value::Constant {
 value,
 disambiguator: Some(disambiguator),
 })
 }
}

The module header explains the third case:

text

//! # Determinism of constant propagation
//!
//! When registering a new `Value`, we attempt to opportunistically evaluate it as a constant.
//! The evaluated form is inserted in `evaluated` as an `OpTy` or `None` if evaluation failed.
//!
//! The difficulty is non-deterministic evaluation of MIR constants. Some `Const` can have
//! different runtime values each time they are evaluated. This happens with valtrees that
//! generate a new allocation each time they are used. This is checked by `is_deterministic`.

Where it lives

compiler/rustc_mir_transform/src/gvn.rs — VnOpaque, ValueSet, new_pointer, insert_constant, is_deterministic.

Takeaway

When you have a class of values that must never be equal, do not give them a “probably different” disambiguator. Give them a marker type whose equality is a trap, route them through a separate insertion path, and let the type system carry the invariant. The compiler bug this prevents — merging two mutable borrows — is exactly the kind that survives years of testing, because the trigger is rare and the symptom is a wrong answer rather than a crash.