Segfault in safe code caused by a use after drop when using index sugar

[phsym]

I've been playing a bit around std::ops::Index and the associated sugar.
I found a case where it may cause a segfault. I tried to reproduce the issue in a simplified code and got the following one (also available on playpen)

use std::ops::Index;

struct Test<'a> {
    s: &'a String
}

impl <'a> Index<usize> for Test<'a> {
    type Output = Test<'a>;
    fn index(&self, _: usize) -> &Self::Output {
        return &Test { s: &self.s};
    }
}

fn main() {
    let s = "Hello World".to_string();
    let test = Test{s: &s};
    let r = &test[0];
    println!("{}", test.s); // OK since test is valid
    println!("{}", r.s); // Segfault since value pointed by r has already been dropped
}

I guess this code should not compile since on the last line, r points to a dropped value.

[alexcrichton]

Hm, this shouldn't compile because return &Test { s: &self.s}; is returning a temporary which can't live as long as self. Seems odd that it does though! I've confirmed that this compiles on all of stable/beta/nightly.

cc @rust-lang/compiler, perhaps this is a dupe of an existing bug?

[durka]

It doesn't actually have to do with the Index sugar: http://is.gd/6sCgIy. It seems like it has to do with copying the lifetime bound from the associated type into the function return type: if you manually substitute in Test<'a> for Self::Output on line 19, then it doesn't compile.

[eddyb]

@alexcrichton I would've guessed it's similar to #29861.

[nikomatsakis]

triage: P-high

[MagaTailor]

Why does it not compile on nightly in playpen?

[eddyb]

@petevine Could be #29861, or some other recent fix.

[durka]

So this seems like it can be closed?