Iterator invalidation not caught by borrow-checker

[Boddlnagg]

In the following reduced code the call to do_bad_thing invalidates the iterator in main.

fn do_bad_thing(grid: &mut Vec<Vec<u8>>) {
    grid[0] = vec![];
}

fn main() {
    let mut v: Vec<Vec<u8>> = vec![vec![1,2,3,4,5]];
    for i in v[0].iter() {
        println!("i = {}", i);
        do_bad_thing(&mut v);
    }
}

Running this locally produces (without optimizations):

i = 1
i = 2
i = 32
i = 0
i = 61

On playpen this does not give wrong results, but it does compile (which is the actual problem).

I'm running rustc on Windows:

rustc --version
rustc 0.13.0-nightly (7e11b2271 2014-12-24 20:47:12 +0000)

[pythonesque]

(1) I can replicate the same issue (at least, I'm pretty sure it's the same issue) in Rust 0.12.

(2) No unsafe code need be involved.

(3) It appears to be a combined problem with the interaction of Deref and Index (it's possible that this testcase can be reduced further, but it seems like both are necessary to demonstrate the problem).

Code below (the #![feature(if_let)] is for Rust 0.12).

---

#![feature(if_let)]

struct Foo<T> { x: T }

impl<T> Index<uint,T> for Foo<T> {
    fn index(&self, _: &uint) -> &T {
        &self.x
    }
}

struct Bar<T> { x: T }

impl<T> Deref<T> for Bar<T> {
    fn deref(&self) -> &T {
        &self.x
    }
}

struct Baz<T> { x: T }

impl<T> Baz<T> {
    fn foo(&self) -> &T {
        &self.x
    }
}

fn main() {
    let u = 1u8;
    let mut v = Foo { x: Bar { x: Baz { x: Some(&u) } } };
    let i = v[0].foo();
    if let Some(ref i) = *i {
        v.x.x.x = None;
        println!("i = {}", i);
    }
}

[nikomatsakis]

I'll check it out (if @eddyb doens't figure it out first!)

[eddyb]

What's very interesting is that (v[0]).foo() does cause the error - my initial guess was that overloaded indexing requires adding adjustments on the v[0] expression, and the overloaded autoderef required to call .foo also needs to add adjustments to v[0], and having an intermediary expression keeps them separate.
The solution there would be to add adjustments instead of replacing them - but! - I can't find a place where ExprIndex causes adjustments to be inserted (i.e. the dereference in *v.index(&0) is implicit), which kinda makes sense, however, that invalidates my hypothesis.
There might still be such a conflict - we could debug by changing, e.g. write_adjustment, to assert that there was nothing in the map that is being replaced.
Actually, please make that happen always, it's a such a nasty bug to hide.

[nikomatsakis]

This may be a bug in the for loop handling code. When I do various transforms to the code, such as storing the iterator in a local, I get the expected error messages.

[eddyb]

@nikomatsakis I found some of those a long while ago (#17068), guess there's more?
Wait, no the test case above has no for loops at all!

[pythonesque]

@nikomatsakis It's not related to for.

[nikomatsakis]

Fix pending.

[nikomatsakis]

See PR #20751