Skip to content
This repository

Change how scope of & is computed #2979

Closed
nikomatsakis opened this Issue July 20, 2012 · 0 comments

1 participant

Niko Matsakis
Niko Matsakis
Collaborator

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.

Niko Matsakis nikomatsakis closed this issue from a commit July 26, 2012
Niko Matsakis 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.
5d32d03
Niko Matsakis nikomatsakis closed this in 5d32d03 July 30, 2012
Jay Anderson jayanderson referenced this issue from a commit November 10, 2013
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.