Borrow compilation error with vec.swap(0, vec.len() - 1), while vec.push(vec.len()) works.

[marcospb19]

I tried compiling this code (here is the playgound link):

fn main() {
    let mut vec = vec![];
    
    vec.push(vec.len());
    vec.push(vec.len() - 1);    // This works!
    vec.swap(0, vec.len() - 1); // Error
}

I expected a Successful compilation, but this happened:

error[E0502]: cannot borrow `vec` as immutable because it is also borrowed as mutable

 --> src/main.rs:6:17
  |
6 |     vec.swap(0, vec.len() - 1);
  |     --- ----    ^^^ immutable borrow occurs here
  |     |   |
  |     |   mutable borrow later used by call
  |     mutable borrow occurs here

Note 1: that the line above the error also contains vec.len(), but it compiles.
Note 2: vec.swap(0, vec.len()); produces the same error (nothing to do with - 1).

Meta

rustc --version --verbose:

rustc 1.44.1
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.44.1
LLVM version: 10.0

Also confirmed in the playground against Nightly and Beta.

[jonas-schievink]

two-phase borrows don't seem to work with autoderef at all, but I'm not sure if there's a canonical issue for that

[dlight]

Is autoderef happening in both of them or just in the vec.swap(..) case?

[jonas-schievink]

push is a method on Vec, so no autoderef is needed. swap is defined on slices, so one autoderef step is needed to call it.

[dlight]

swap is defined on slices but also on Vec, so no autoderef should be needed.

edit: actually, no, the method on Vec is the slice one.. this should be displayed in the docs somehow. it is

[jonas-schievink]

No, that is in "Methods from Deref<Target = [T]>"

[nbdd0121]

That line is actually

<[_]>::swap(<Vec<_> as DerefMut>::deref_mut(&mut vec), 0, Vec::len(&vec) - 1);

And currently the <Vec<_> as DerefMut>::deref_mut would have to evaluate before Vec::len, which will fail borrowck.

[marcospb19]

I ran into the same issue again.

This did not compiled:

merge_sort(&mut v[..v.len()]);
merge_sort(&mut v[v.len()..]);

But this did:

let temp = v.len() / 2;
merge_sort(&mut v[..temp]);
merge_sort(&mut v[temp..]);

The signature:

fn merge_sort(v: &mut [i32]) { ... }

---

I'm out of context, are there any other other opened issues referencing this problem?

Will Polonius be able to fix it?

[nbdd0121]

Will Polonius be able to fix it?

No. As I mentioned earlier, the desugared code will use a mutable borrow before an immutable one, so this code should not compile, otherwise it is unsound in general. To make NLL work across autoderef would likely be a langauge-level major change because the compiler'll need to move the location of autoderef.

[yume-chan]

This doesn't compile:

vec[vec.len() - 1] = 0;

But this does: (playground)

use std::ops::IndexMut;
*vec.index_mut(vec.len() - 1) = 0;

The doc of IndexMut says

container[index] is actually syntactic sugar for *container.index_mut(index), but only when used as a mutable value.

No, clearly not, there is magic between them.

---

But this doesn't compile

*vec.get_mut(vec.len() - 1).unwrap() = 0;

Nor this:

*std::ops::IndexMut::index_mut(&mut vec, vec.len() - 1) = 0;

---

What's the difference?

[nbdd0121]

No, clearly not, there is magic between them.

container[index] is indeed just a syntactic sugar, but it does not have two-phase borrow enabled, while two-phase borrow is enabled for a plain method call. This is actually intentional.

rust/compiler/rustc_typeck/src/check/place_op.rs

Lines 376 to 380 in 96859db

	// Deref/indexing can be desugared to a method call,
	// so maybe we could use two-phase here.
	// See the documentation of AllowTwoPhase for why that's
	// not the case today.
	allow_two_phase_borrow: AllowTwoPhase::No,

Related: #49434

[pnkfelix]

(I had put a big comment here but then I realized that this issue isn't specifically about IndexMut, so I moved my comment over to #58419, which is specifically about IndexMut (I think)...)