Leak when binding a stack closure

[brson]

This example from the language reference leaks

fn main() {
    fn add(x: int, y: int) -> int {
        ret x + y;
    }

    type single_param_fn = fn(int) -> int;

    let add4: single_param_fn = bind add(4, _);
    let add5: single_param_fn = bind add(_, 5);

    assert (add(4,5) == add4(5));
    assert (add(4,5) == add5(4));
}

Unreclaimed object found at 0x678b7a0: ((), (5))
Unreclaimed object found at 0x678b730: ((), (4))
rust: fatal, 'leaked memory in rust main loop (2 objects)' failed, ../src/rt/memory_region.cpp:158 2 objects

[marijnh]

For me (on Linux) this program doesn't leak and is Valgrind-clean.

[brson]

I dug a little deeper and the problem is with declaring the type as a stack closure. Here's a reduced test:

fn main() {
    fn add(x: int) {
    }

    let add4: fn() = bind add(4);
}

Declaring add4 as fn@() works

[nikomatsakis]

Interesting. I can see why this fails, yes. The problem is that we have no cleanup for fn() types (and rightly so)... we assume that an fn() variable is an alias for an fn@() somewhere else. So here the problem is when we upcast the fn@() to an fn().

This is in fact a borrowing operation (a la regions) and I can probably fix this bug at the same time as I implement borrowing more generally.

[nikomatsakis]

Actually, the simpler fix is just to prevent fn() from being stored in a local variable---just as we do with fn&().

[catamorphism]

Obsolete, since we no longer have bind ( #2189 ). Closing.