@@ -283,23 +283,27 @@ pub struct ScopeTree {
283
283
/// To see that this method works, consider:
284
284
///
285
285
/// 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`.
289
289
///
290
290
/// Remember that storage-live/storage-dead refers to the state of
291
291
/// the *storage*, and does not consider moves/drop flags.
292
292
///
293
293
/// Then:
294
+ ///
294
295
/// 1. From the ordering guarantee of HIR visitors (see
295
296
/// `rustc_hir::intravisit`), `D` does not dominate `U`.
297
+ ///
296
298
/// 2. Therefore, `D` is *potentially* storage-dead at `U` (because
297
299
/// we might visit `U` without ever getting to `D`).
300
+ ///
298
301
/// 3. However, we guarantee that at each HIR point, each
299
302
/// binding/temporary is always either always storage-live
300
303
/// or always storage-dead. This is what is being guaranteed
301
304
/// by `terminating_scopes` including all blocks where the
302
305
/// count of executions is not guaranteed.
306
+ ///
303
307
/// 4. By `2.` and `3.`, `D` is *statically* storage-dead at `U`,
304
308
/// QED.
305
309
///
0 commit comments