Stealing Mechanism in MIR Processing Pipeline

optimization to avoid cloning the MIR. Attempting to use a stolen result will cause a panic in the compiler. Therefore, it is important that you do not accidentally read from these intermediate queries without the consideration of the dependency in the MIR processing pipeline. Because of this stealing mechanism, some care must be taken to ensure that, before the MIR at a particular phase in the processing pipeline is stolen, anyone who may want to read from it has already done so. Concretely, this means that if you have a query `foo(D)` that wants to access the result of `mir_promoted(D)`, you need to have `foo(D)` calling the `mir_const(D)` query first. This will force it to execute even though you don't directly require its result. > This mechanism is a bit dodgy. There is a discussion of more elegant alternatives in [rust-lang/rust#41710]. ### Overview Below is an overview of the stealing dependency in the MIR processing pipeline[^part]: ```mermaid flowchart BT mir_for_ctfe* --borrow--> id40 id5 --steal--> id40 mir_borrowck* --borrow--> id3 id41 --steal part 1--> id3 id40 --steal part 0--> id3 mir_const_qualif* -- borrow --> id2 id3 -- steal --> id2 id2 -- steal --> id1 id1([mir_built]) id2([mir_const]) id3([mir_promoted]) id40([mir_drops_elaborated_and_const_checked]) id41([promoted_mir]) id5([optimized_mir]) style id1 fill:#bbf style id2 fill:#bbf style id3 fill:#bbf style id40 fill:#bbf style id41 fill:#bbf style id5 fill:#bbf ``` The stadium-shape queries (e.g., `mir_built`) with a deep color are the primary queries in the pipeline, while the rectangle-shape queries (e.g., `mir_const_qualif*`[^star]) with a shallow color are those subsequent queries that need to read the results from `&'tcx Steal<Body<'tcx>>`. With the stealing mechanism, the rectangle-shape queries must be performed before any stadium-shape queries, that have an equal or larger height in the dependency tree, ever do. `(&'tcx Steal<Body<'tcx>>, &'tcx Steal<IndexVec<Promoted, Body<'tcx>>>)`, `promoted_mir` will steal part 1 (`&'tcx Steal<IndexVec<Promoted, Body<'tcx>>>`) and `mir_drops_elaborated_and_const_checked` will steal part 0 (`&'tcx Steal<Body<'tcx>>`). And their stealing is irrelevant to each other, i.e., can be performed separately. For example, `mir_borrowck*` represents `mir_borrowck`, `mir_borrowck_const_arg` and `mir_borrowck_opt_const_arg`. ### Example As an example, consider MIR const qualification. It wants to read the result produced by the `mir_const` query. However, that result will be **stolen** by the `mir_promoted` query at some time in the pipeline. Before `mir_promoted` is ever queried, calling the `mir_const_qualif` query will succeed since `mir_const` will produce (if queried the first time) or cache (if queried multiple times) the `Steal` result and the result is **not** stolen yet. After `mir_promoted` is queried, the result would be stolen and calling the `mir_const_qualif` query to read the result would cause a panic. Therefore, with this stealing mechanism, `mir_promoted` should guarantee any `mir_const_qualif*` queries are called before it actually steals, thus ensuring that the reads have already happened (remember that [queries are memoized](../query.html), so executing a query twice simply loads from a cache the second time).

This section explains the stealing mechanism in the MIR processing pipeline, where intermediate queries like `mir_const` and `mir_promoted` yield a `Steal<Body<'tcx>>`. This mechanism aims to avoid cloning the MIR, but it requires careful management of dependencies. The rectangle-shape queries must be performed before any stadium-shape queries, that have an equal or larger height in the dependency tree, ever do. The example of MIR const qualification is used to illustrate how `mir_promoted` must ensure that any `mir_const_qualif*` queries are called before it steals the result from `mir_const`.