mention that granting used to be matching
[web.git] / ralf / _posts / 2019-04-30-stacked-borrows-2.md
index d9037c06db94bcd337920a5b0d35b1008a4efbb3..8436bff12d820f64378f102163771c9e11172ea4 100644 (file)
@@ -88,6 +88,7 @@ For each affected location, we go through two steps: first we try to find the *g
 **Finding the granting item.**
 To find the granting item, we traverse the borrow stack top-to-bottom and search for an item that has the same tag.
 If this is a write access, we go on looking until we find an item with the right tag whose permission is `SharedReadWrite` or `Unique`---we do not consider items with `SharedReadOnly` permission to grant a write access.
+This is the item that grants pointers tagged `tag` the permission to perform the given access, hence the name (the same concept used to be called "matching item" in Stacked Borrows 1).
 Once we found the granting item, we remember its position in the stack; that will be important for the second step.
 If no granting item can be found, the access causes undefined behavior.
 
@@ -366,4 +367,4 @@ It puts us into a good position to do more precise tracking for raw pointers, si
 That will be needed for compatibility with LLVM.
 However, [there are still some known issues](https://github.com/rust-lang/unsafe-code-guidelines/issues?q=is%3Aissue+is%3Aopen+label%3Atopic-stacked-borrows), and also the fact that we do not actually use the "stack" as a stack indicates that maybe we should use a different structure there (potentially something more like a tree).
 This is definitely not the final word, but I think it is a step in the right direction, and I am curious to see how it works out.
-As usual, if you have any questions or comments, please join the discussion in the forums!
+As usual, if you have any questions or comments, please join the [discussion in the forums](https://internals.rust-lang.org/t/stacked-borrows-2/9951)!