Use a MIR dataflow analysis pass to prevent moves instead of basing it on lifetime of borrows.

Author: Zoxc

text/0000-immovable-types.md

@@ -30,49 +30,9 @@ You can freely move values which are known to implement `Move` after they are bo
 
 Static variables allow types which do not implement `Move`.
 
-## Borrowing immovable types
+## Move checking
 
-Borrowing values of types which do not implement `Move` is only allowed if the borrows lasts for the entire lifetime of the values, including the drop of the value, since `drop` takes a reference to it. Reborrows of such borrows follow existing rules.
-
-This means that the following borrow would not be allowed:
-```rust
-let mutex = StaticMutex::new(0);
-{
-	*mutex.lock() += 1;
-}
-let moved = mutex;
-*moved.lock() += 1;
-```
-Here `lock` borrows the `mutex` variable. The borrow only last until the end of the same statement. That means we'd be allowed to move `mutex` into a new variable `moved` and call `lock` on it, this time with an different address for `&self`!
-
-We rely on the fact that borrows prevent moves. We cannot change the lifetime of the borrow to encompass the moving statement using the current borrow checker. This can be changed once we get non-lexical lifetime and we'd get an error on the move instead.
-
-Conceptually we can think of borrows of `?Move` values as introducing 2 borrows:
-- one borrow with as short lifetime as possible with normal restrictions
-- one borrow which must match the lifetime of the borrowed value. The only restriction placed is that the value must not be moved out of.
-
-This RFC suggests an approach where we use only the shorter borrow and require it to match the lifetime of the value. This is less flexible, but results in minimal implementation changes. A more flexible solution can be introduced with non-lexical lifetimes.
-
-We can easily work around issues with this in code by using a single borrow of the immovable value and just reborrow.
-
-Illegal:
-```rust
-let mutex = StaticMutex::new(0);
-*mutex.lock() += 1;
-*mutex.lock() += 1;
-```
-Workaround using reborrows:
-```rust
-let mutex = &StaticMutex::new(0);
-*mutex.lock() += 1;
-*mutex.lock() += 1;
-```
-
-A borrow such as `&var.field` where `field` is immovable will last as long as the lifetime of `var` to ensure it matches the lifetime of the field.
-
-We need to prevent assignment to immovable types once they have been borrowed. This is because assignment actually moves the l-value before calling `Drop::drop`. If there are any restrictions on the l-value or if the l-value has a dereference operation, assignment to immovable types is not allowed.
-
-Types which implement `Copy`, but not `Move` are allowed. You can still copy them around, but borrows follows the restrictions of `?Move` types.
+To prevent values which may not implement `Move` that have been previously borrowed we introduce a MIR pass. We do a forward dataflow analysis on the MIR marking l-values that have been borrowed. For `a` we mark the path `a` as observed. For `a.b` we mark both `a.b` and the parent `a`, since if you observe `a.b` moving `a` will change the address of `a.b`. For `*a` we do nothing, as the address of `a` isn't observed. For slice indices `a[i]`, we mark `a` as observed. Finally we walk through every move in the MIR and give an error if the moved value could be observed at that point and the type of the value isn't known to implement `Move`.
 
 ## Immovable types contained in movable types