Mutable vector modified in-place while evaluating right side of assignment

[MrAlert]

Assigning to a mutable vector causes it to be modified in-place even if the right side of the assignment references it.

#[test]
fn mutable_vector_in_place_assignment () {
    let mut t = [1u, ..2];
    t = [t[1] * 2, t[0] * 2];
    assert_eq!(t.as_slice(), &[2, 2]);
}

running 1 test
test mutable_vector_in_place_assignment ... FAILED

failures:

---- mutable_vector_in_place_assignment stdout ----
        task 'mutable_vector_in_place_assignment' failed at 'assertion failed: `(left == right) && (right == left)` (left: `[2, 4]`, right: `[2, 2]`)', test2.rs:5



failures:
    mutable_vector_in_place_assignment

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured

task '<main>' failed at 'Some tests failed', /build/rust-git/src/rust/src/libtest/lib.rs:242

On IRC, @Kimundi pointed me to #15300, which might be related.

[alexcrichton]

Nominating. This may not be a 1.0 backcompat-lang issue though as it seems fairly rare.

[ghost]

Same thing with structs:

struct A {
  pub x: uint,
  pub y: uint
}

fn main() {
  let mut a = A { x: 1, y: 1 };
  a = A { x: a.y * 2, y: a.x * 2 };
  assert_eq!(a.x, 2);
  assert_eq!(a.y, 2);
}

[MrAlert]

OK, same thing happens with enums, which is a bit more serious since it now affects memory safety.

#[deriving(Show)]
enum Foo {
    Bar(uint, uint),
    Baz(&'static uint, &'static uint)
}

static num: uint = 100;

fn main () {
    let mut b = Baz(&num, &num);
    b = Bar(f(&b), g(&b));
    println!("main: {}", b);
}

static fnum: uint = 1;

fn f (b: &Foo) -> uint {
    println!("f   : {}", b);
    fnum
}

static gnum: uint = 2;

fn g (b: &Foo) -> uint {
    println!("g   : {}", b);
    gnum
}

f   : Baz(100, 100)
Segmentation fault

[nikomatsakis]

I believe this problem is in trans -- it is supposed to used a temporary buffer for these sorts of cases, but obviously that check is not working correctly.

[pnkfelix]

Team believes this to be a miscompilation issue (and not, as we feared at first, a failure of the borrow-checker to reject an incorrect program). That is, these programs should be compilable; the problem is that the generated code is wrong.

P-high, not 1.0.

[pnkfelix]

All of the code examples from this ticket seem to work now:

• playpen for example 1
• playpen for example 2
• playpen for example 3

So I think this just needs regression tests.