unused var causes copying of resource type

[rntz]

The following program prints "0\n0\n", when it should print "0\n":

resource echo(x: {mut a: int}) {
    io::println(#fmt("%d", x.a));
    x.a += 1;
}

fn main() {
    let x = [echo({mut a: 0})];
    let y = x;
}

The same effect occurs if you rename y to _y to eliminate the unused variable warning. The same effect does not occur if you use y, eg the following program has correct behavior:

resource echo(x: {mut a: int}) {
    io::println(#fmt("%d", x.a));
    x.a += 1;
}

fn main() {
    let x = [echo({mut a: 0})];
    let y = x;
    y;
}

The use of a record with a mutable field is also not essential to the bug; I used it to demonstrate that the bug is actually due to copying, and not running the destructor twice on the same value.

[pcwalton]

I suspect the no-implicit-copies proposal fixes this.

[nikomatsakis]

in theory, resources ought not to be copyable in the first place.

[msullivan]

y is a last-use of x, though, so it isn't a copy, it's a move, right?

[nikomatsakis]

indeed. I presume then that this is a bug in trans, where the last_use information is not being used and so a copy is induced.

[nikomatsakis]

hmm, my theory may not hold water. it's not clear to me why using y would prevent the error, then.

[msullivan]

It looks like the bug is in the code for initializing locals when it has been determined that they can be kept off of the stack. As it turns out, basically the only way to keep liveness from saying something needs to be kept on the stack is for it to be unused.

I'm just going to fix this by getting rid of the stuff where we avoid spilling variables. It never seems to get used and llvm can do it anyways.

[nikomatsakis]

@msullivan is this bug specifically in the code that you will be deleting? or is it some more general thing in the treatment of immediates?

[msullivan]

I believe the bug is specifically in the code for immediate local variable initialization, but similar bugs might lurk elsewhere.