
Stacked Borrows: An Aliasing Model for Rust - pjmlp
https://plv.mpi-sws.org/rustbelt/stacked-borrows/
======
PudgePacket
There's a talk here
[https://www.youtube.com/watch?v=h9Fh4jRDGLo](https://www.youtube.com/watch?v=h9Fh4jRDGLo)
and some extra info here [https://github.com/rust-lang/unsafe-code-
guidelines/blob/mas...](https://github.com/rust-lang/unsafe-code-
guidelines/blob/master/wip/stacked-borrows.md)

------
mjw1007
It seems to me that there are three pieces we'd like to have, to show that we
can trust Rust's borrow checker as much as we'd like to:

\- a runtime model of a hypothetical dialect of Rust without a borrow checker,
defining which programs have undefined behaviour because they access memory
"wrongly";

\- a compiler for that dialect, in practice built on LLVM, that gives LLVM
permission to invoke undefined behaviour only in cases where the model says
that's allowed;

\- a demonstration that any program in the hypothetical dialect that can
invoke undefined behaviour either uses `unsafe` or is rejected by the borrow
checker.

As I understand it, this paper is a plan for providing the first, and the
compiler people think it's possible to use it to provide the second.

Has the third been done, or is someone working on it?

~~~
kd5bjo
> a demonstration that any program in the hypothetical dialect that can invoke
> undefined behaviour either uses `unsafe` or is rejected by the borrow
> checker.

This isn’t quite what they’re doing here. They’re trying to define what
guarantees the compiler should make about its treatment of unsafe code to
strike a balance between usability and the ability of the compiler to
optimize.

~~~
mjw1007
Sure, but we want to be sure that the chosen model fits in correctly with the
borrow checker. That's the part I was interested in.

~~~
kd5bjo
My apologies; I misread your original statement to imply that unsafe would
necessarily imply undefined behavior.

------
d33
Didn't really get it. Does it speed programs up, or allow better guessing or
when borrow checking isn't actually violated? If the former, what kind of
situations is the program sped up in?

~~~
maikklein_dev
If I understood it correctly, it just turns undefined behavior regarding
aliasing into compiler errors

~~~
hyperman1
My take on this: There are certain properties all rust code should have.

In safe rust, the compiler gives a mathematical proof this is so. In unsafe
code, the compiler does not, but still assumes these properties are holding.
The burden to make sure everything is correct falls on the shoulders of the
programmers.

But nobody knows exactly what these properties are. There is a big part known,
but the edges are fuzzy. So unsafe code is required to follow rules nobody
knows.

This effort is part of the work to clarify the rules. If accepted, both the
compiler and unsafe programmer knows how far they are allowed to go

~~~
littlestymaar
That's a really good summary, thank you.

