stack allocated vecs can be returned from functions

[erickt]

See this gist: https://gist.github.com/3419521, with the attached llvm bitcode. Rust compiles it fine, but looking through the bitcode, it appears that rust is returning a stack pointer.

[catamorphism]

Reproduced as of d2ad028

[graydon]

Hm. I think this is just returning the slice, which is ok, no? The lifetime is static, and it outlives the caller lifetime as inferred..

[ghost]

@graydon Well, that example is a bit unfortunate but the following compiles too:

fn main() {
    for (|| &[1, 2, 3])().each |i| {
        io::println(fmt!("%d", *i));
    }
}

and prints out rubbish for me.

[graydon]

That's also fine. &[1,2,3] is a slice to a static array (i.e. with unlimited lifetime). Or .. it should be!

[graydon]

Oh. I guess if it prints out rubbish it's probably compiling as non-static. Yeah, that's bad.

[thestinger]

Stack arrays should be returned by-value (so through an output parameter). They can't be static because they're mutable.

[pnkfelix]

Reproduced as of c202430

Here is a slightly elaborated version of fawek's example that I used to better understand the scenario:

const some_array : &'static [int] = &'static [1,2,3];

fn main() {
    io::println("Direct");
    for [1, 2, 3].each |i| {
        io::println(fmt!("%d", *i));
    }

    io::println("Indirect global");
    for (|| &some_array)().each |i| {
        io::println(fmt!("%d", *i));
    }

    io::println("Indirect local");
    for (|| &[1, 2, 3])().each |i| {
        io::println(fmt!("%d", *i));
    }
}

On my machine, it prints:

Direct
1
2
3
Indirect global
1
2
3
Indirect local
24
140552821560312
24

[graydon]

mhm. definitely disappointing and worth fixing (keeping those importance labels) but I don't think it's a showstopper for 0.6. removing milestone.

[metajack]

Still reproducible,, thought I get slightly different output.

Nominating for production ready.

[graydon]

accepted for production-ready milestone

[lilyball]

This is a pretty nasty and subtle bug. Just spent a while trying to figure out how the heck I was getting [0] back, and finally tracked it down to returning the results of bytes!(".") and having that transform into &[0] behind my back. Given how easy it is to accidentally trigger (especially with bytes!()) I think it should be a bit higher priority.

[nikomatsakis]

@kballard yes, you're right. I'll take a look, I suspect the fix is fairly straightforward.

[pnkfelix]

accepted for P-backcompat-lang.

[nikomatsakis]

This was fixed as part of #3511. However, no test case. I'll add one.