From: Ralf Jung Date: Mon, 15 Oct 2018 16:28:15 +0000 (+0200) Subject: clarify retagging onm fn enter X-Git-Url: https://git.ralfj.de/web.git/commitdiff_plain/9d1fd88af8dc553c0d7f5951dfbd38cefd8b729c?ds=sidebyside clarify retagging onm fn enter --- diff --git a/ralf/_posts/2018-08-07-stacked-borrows.md b/ralf/_posts/2018-08-07-stacked-borrows.md index 54dd417..6469a1d 100644 --- a/ralf/_posts/2018-08-07-stacked-borrows.md +++ b/ralf/_posts/2018-08-07-stacked-borrows.md @@ -442,7 +442,7 @@ Now we can look at what happens for each operation. - Compute `new_bor` from `new_tag` and the type of the reference being created. - `reactivate(bor)`. - If this is a function argument coming in: `loc.borrows.push(FnBarrier(stack_height))`. - - `initiate(new_bor)`. Note that this is a NOP if `new_bor` is already active -- in particular, if the location is frozen and this is a shared reference with interior mutability, we do *not* push anything on top of the barrier. This is important, because we do not want to push that might unfreeze the location when being reactivated. + - `initiate(new_bor)`. Note that this is a NOP if `new_bor` is already active -- in particular, if the location is frozen and this is a shared reference with interior mutability, we do *not* push anything on top of the barrier. This is important, because any reactivation that unfreezes this location must lead to UB while the barrier is still present. - Change reference tag to `new_tag`. * Any time a raw pointer is created from a reference, we might have to do a raw reborrow. - `reactivate(bor)`.