Cleanup region hierarchy code, especially around closures

[nikomatsakis]

This is a big that's been on the back of my mind for a while but I don't think it has a bug associated with it. When we build the region hierarchy, we assume that any ||-closure argument is limited to the lifetime of the call where it appears. However, since the more general form of fn& was implemented, I don't believe this is enforced. We should place an upper-bound on the || lifetime and add some tests. In an ideal world, maybe we would always infer the lifetime of an ||-closure, but this is tricky to do because the region hierarchy is built before region inference (and indeed it must be, in order to compute LUB/GLB and so forth).

[bblum]

I had a weird idea a while ago, for a higher-order function involving returning a stack closure something like:

fn a(blk: &a/fn(c: &blk/fn() -> &blk/fn())) {
    let d = || { ... };
    do blk {
        return d;
    }
}

And then use it like:

do a |c| {
    let d = c();
    d(); // 'd' cannot escape this block
}

I recall that I couldn't make it compile. This sounds like it might enable this (crazy, but cool) sort of thing.

[nikomatsakis]

An example from #3283 that should not build but does (leading to segfaults):

fn foo(+blk: fn(+p: &a/fn() -> &a/fn())) {
    let mut state = 0;
    let statep = &mut state;
    do blk {
        || { *statep = 1; }
    }
}
fn main() {
    do foo |p| { p()() }
}

[emberian]

Could not get to compile with:

fn foo<'a>(blk: &fn(p: &'a fn() -> &'a fn())) {
    let mut state = 0;
    let statep = &mut state;
    do blk {
        || { *statep = 1; }
    }
}
fn main() {
    do foo |p| { p()() }
}

[nikomatsakis]

I did fix some problems in this area though this is still an issue. I have to come up with a good representative test case.

[catamorphism]

@nikomatsakis Does #2202 subsume this, or is there still something left to do?

[edwardw]

The PR #12828 tries to apply variance rule to self type substitution, also part of #5781, but the following begins to fail:

pub fn main() {
    let a = ~[~""];
    let b: ~[~[&str]] = a.map(|s| s.lines().collect()); // error: cannot infer an appropriate lifetime for autoref due to conflicting requirements
}

First of all, should this compile as it currently does? If yes, then how is the self type substitution intertwined with with closure lifetime inference?

[nikomatsakis]

@bkoropoff I'd love to talk over this issue with you if you're interested in looking at something else after #17403 :) -- I think the two are related, or at least touching pretty similar code.

[nikomatsakis]

@pnkfelix has been working on this

[steveklabnik]

@nikomatsakis what's the state of this with the new closure stuff? is it still relevant?

[nikomatsakis]

I'm updating the title on this issue and repurposing it to also cover the fact that it would be nice if the representation of "free" regions did not always have them attached to a scope. Instead, a free region should just have a number, and we should indicate the relationship that A >= X for some scope X as an in-scope where clause.

[brson]

@nikomatsakis Still a bug?

[nikomatsakis]

So this is still a bug, but I hope that we will fix it for good once we fully move borrow/region-checking to MIR. The idea is that MIR has fully desugared closures. I am going to close this bug though because it's kind of vague and I don't see how having it open is helpful in any particular way.