@@ -361,16 +361,19 @@ pub enum StatementKind<'tcx> {
361
361
/// At any point during the execution of a function, each local is either allocated or
362
362
/// unallocated. Except as noted below, all locals except function parameters are initially
363
363
/// unallocated. `StorageLive` statements cause memory to be allocated for the local while
364
- /// `StorageDead` statements cause the memory to be freed. Using a local in any way (not only
365
- /// reading/writing from it) while it is unallocated is UB.
364
+ /// `StorageDead` statements cause the memory to be freed. In other words,
365
+ /// `StorageLive`/`StorageDead` act like the heap operations `allocate`/`deallocate`, but for
366
+ /// stack-allocated local variables. Using a local in any way (not only reading/writing from it)
367
+ /// while it is unallocated is UB.
366
368
///
367
369
/// Some locals have no `StorageLive` or `StorageDead` statements within the entire MIR body.
368
370
/// These locals are implicitly allocated for the full duration of the function. There is a
369
371
/// convenience method at `rustc_mir_dataflow::storage::always_storage_live_locals` for
370
372
/// computing these locals.
371
373
///
372
- /// If the local is already allocated, calling `StorageLive` again is UB. However, for an
373
- /// unallocated local an additional `StorageDead` all is simply a nop.
374
+ /// If the local is already allocated, calling `StorageLive` again will implicitly free the
375
+ /// local and then allocate fresh uninitilized memory. If a local is already deallocated,
376
+ /// calling `StorageDead` again is a NOP.
374
377
StorageLive ( Local ) ,
375
378
376
379
/// See `StorageLive` above.
0 commit comments