From 242ee8a77857b91ca31b74ed8865bc49266a3d2d Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Mon, 15 Oct 2018 18:28:15 +0200 Subject: [PATCH] clarify retagging onm fn enter --- personal/_posts/2018-08-07-stacked-borrows.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/personal/_posts/2018-08-07-stacked-borrows.md b/personal/_posts/2018-08-07-stacked-borrows.md index 54dd417..6469a1d 100644 --- a/personal/_posts/2018-08-07-stacked-borrows.md +++ b/personal/_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)`. -- 2.30.2