Accessing &mut through & oddities

[alexcrichton]

This program fails to compile:

struct A<'a> { b: &'a mut int }

fn foo(a: &A) {
    *a.b = 3;
}

fn main() {
    let mut a = 2;
    let b = A { b: &mut a };
    foo(&b);
}

whereas this program succeeds to compile

struct A<'a> { b: &'a mut int }

fn bar(a: &mut int) { *a = 2; }

fn foo(a: &A) {
    bar(a.b);
    bar(a.b);
}

fn main() {
    let mut a = 2;
    let b = A { b: &mut a };
    foo(&b);
}

These seem to be doing the same thing to me, so I would expect both of them to be rejected or both of them be accepted.

cc @nikomatsakis

[flaper87]

Adding more info (perhaps not actually necessary for this bug). Treating everything as mutable succeeds as well.

struct A<'a> { b: &'a mut int }

fn foo(a: &mut A) {
    *a.b = 3;
}

fn main() {
    let mut a = 2;
    let mut b = A { b: &mut a };
    foo(&mut b);
}

[nikomatsakis]

Agreed, this is wrong. The mutable borrow in the second case should definitely be disallowed.

[alexcrichton]

Nominating.

[pnkfelix]

1.0, P-backcompat-lang

[nikomatsakis]

The problem seems to be that we removed RESTR_ALIAS from the list of things to be restricted, probably when removing const loans.

[kkimdev]

@nikomatsakis Would you mind to explain what can go wrong if we allow this? (I started playing with Rust recently, and encountered a problem that this can solve. So I wondered what can go wrong by allowing this)

[Gankra]

@kkimdev You can get multiple &'s of the same value. If you then allow using an &mut through an & you've basically allowed multiple &mut's to be created. In fact you would be able to trivially bypass mutable aliasing rules with &&mut.

[kkimdev]

@gankro I see, that makes sense!