I have been thinking about how to improve upon Stacked Borrows the past few weeks. Now my first draft of my idea is finished and i would appreciate any feedback greatly.
I have read
- the original paper about Stacked Borrows.
- Ralfj's blog posts.
- UCG's wip section about SB.
So point me to anything I might have missed!
Replacing the stack with a tree is not an original idea, Ralf mentioned it in this blog:
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).
What the tree should improve:
- better interior mutability tracking
- define allowed mutable aliasing
- retain existing behavior
- catch use-after-move errors
- improve handling two-phase borrows
It of course also has some drawbacks (especially the way I defined some of the interactions), but I hope that these are actually advantages (allowing more optimizations/simplifying other areas) or they are worth, because of what they enable us to do.
Any feedback is welcome! Hints to improve the formatting/wording and of course problems with the design itself.
Why is this even needed?
- https://github.com/rust-lang/unsafe-code-guidelines/issues/236
- aliased mutability is not allowed in Rust see Resolve unsound interaction between noalias and self-referential data (incl. generators, async fn) · Issue #63818 · rust-lang/rust · GitHub also discussed in this thread on zulip
- What about: use-after-move and (maybe) use-after-drop · Issue #188 · rust-lang/unsafe-code-guidelines · GitHub
- two-phase borrow weirdness: What exactly are the rules for `UnsafeCell::get_mut`? · Issue #333 · rust-lang/unsafe-code-guidelines · GitHub
- better tracking of a pointer permissions: Stacked Borrows does not support &UnsafeCell pointing to read-only data · Issue #303 · rust-lang/unsafe-code-guidelines · GitHub
I am in no way sure that the proposed idea fixes any of these problems, but I hope that this is a step in the right direction.