@@ -283,23 +283,27 @@ pub struct ScopeTree {
283283 /// To see that this method works, consider:
284284 ///
285285 /// Let `D` be our binding/temporary and `U` be our other HIR node, with
286- /// `HIR-postorder(U) < HIR-postorder(D)` ( in our example, U would be
287- /// the yield and D would be one of the calls). Let's show that
288- /// `D` is storage-dead at `U`.
286+ /// `HIR-postorder(U) < HIR-postorder(D)`. Suppose, as in our example,
287+ /// U is the yield and D is one of the calls.
288+ /// Let's show that `D` is storage-dead at `U`.
289289 ///
290290 /// Remember that storage-live/storage-dead refers to the state of
291291 /// the *storage*, and does not consider moves/drop flags.
292292 ///
293293 /// Then:
294+ ///
294295 /// 1. From the ordering guarantee of HIR visitors (see
295296 /// `rustc_hir::intravisit`), `D` does not dominate `U`.
297+ ///
296298 /// 2. Therefore, `D` is *potentially* storage-dead at `U` (because
297299 /// we might visit `U` without ever getting to `D`).
300+ ///
298301 /// 3. However, we guarantee that at each HIR point, each
299302 /// binding/temporary is always either always storage-live
300303 /// or always storage-dead. This is what is being guaranteed
301304 /// by `terminating_scopes` including all blocks where the
302305 /// count of executions is not guaranteed.
306+ ///
303307 /// 4. By `2.` and `3.`, `D` is *statically* storage-dead at `U`,
304308 /// QED.
305309 ///
0 commit comments