Change how scope of & is computed #2979

nikomatsakis opened this Issue Jul 21, 2012 · 0 comments


None yet

1 participant


Right now we compute the scope of an expression like &expr in a pre-determined fashion. What we should do is to create a region variable and use that instead, with a lower bound of the &expr itself but no upper bound (we should also use this technique for implicit borrows). Inference will then select the smallest scope it can for the resulting region. Finally, in borrowck, make sure that expr can be guaranteed for the result. This will require some modifications to borrowck, I think, to be sure it takes loops and so forth into account for rooting—but that code makes sense to have anyway.

The reason to make this change is that it allows us to select the lifetime of &expr in a variety of ways. If expr is a shared box, or owned by a shared box, we can use the rooting rules which can sometimes be the best. Otherwise, we can use the lifetime of expr itself, which is sometimes the right choice. Basically we can't know until after inference what would be the true upper bound and so we have to check later in a second pass. This isn't a very clear bug report but I'll draw up some examples in the code of what I mean.

This enhancement helps with sendable hashtables and would allow us to do things like return pointers to the interior of data structures in more cases.

@nikomatsakis nikomatsakis was assigned Jul 21, 2012
@nikomatsakis nikomatsakis added a commit that closed this issue Jul 30, 2012
@nikomatsakis nikomatsakis Fix #2979: inference for lifetimes of & expressions
What we now do is to create a region variable for each &
expression (and also each borrow).  The lifetime of this
variable will be checked by borrowck to ensure it is not greater
than the lifetime of the underlying data.  This both leads to
shorter lifetimes in some cases but also longer in others,
such as taking the address to the interior of unique boxes
tht are rooted in region pointers (e.g., returning a pointer
to the interior of a sendable map).

This may lead to issue #2977 if the rvalue is not POD, because
we may drop the data in trans sooner than borrowck expects us
to.  Need to work out precisely where that fix ought to occur.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment