@@ -361,16 +361,19 @@ pub enum StatementKind<'tcx> {
361361 /// At any point during the execution of a function, each local is either allocated or
362362 /// unallocated. Except as noted below, all locals except function parameters are initially
363363 /// 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.
366368 ///
367369 /// Some locals have no `StorageLive` or `StorageDead` statements within the entire MIR body.
368370 /// These locals are implicitly allocated for the full duration of the function. There is a
369371 /// convenience method at `rustc_mir_dataflow::storage::always_storage_live_locals` for
370372 /// computing these locals.
371373 ///
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.
374377 StorageLive ( Local ) ,
375378
376379 /// See `StorageLive` above.
0 commit comments