[][src]Module rustc_typeck::check::upvar

⚙️ This is an internal compiler API. (rustc_private)

This crate is being loaded from the sysroot, a permanently unstable location for private compiler dependencies. It is not intended for general use. Prefer using a public version of this crate from crates.io via Cargo.toml.

Inferring borrow kinds for upvars

Whenever there is a closure expression, we need to determine how each upvar is used. We do this by initially assigning each upvar an immutable "borrow kind" (see ty::BorrowKind for details) and then "escalating" the kind as needed. The borrow kind proceeds according to the following lattice:

ty::ImmBorrow -> ty::UniqueImmBorrow -> ty::MutBorrow

So, for example, if we see an assignment x = 5 to an upvar x, we will promote its borrow kind to mutable borrow. If we see an &mut x we'll do the same. Naturally, this applies not just to the upvar, but to everything owned by x, so the result is the same for something like x.f = 5 and so on (presuming x is not a borrowed pointer to a struct). These adjustments are performed in adjust_upvar_borrow_kind() (you can trace backwards through the code from there).

The fact that we are inferring borrow kinds as we go results in a semi-hacky interaction with mem-categorization. In particular, mem-categorization will query the current borrow kind as it categorizes, and we'll return the current value, but this may get adjusted later. Therefore, in this module, we generally ignore the borrow kind (and derived mutabilities) that are returned from mem-categorization, since they may be inaccurate. (Another option would be to use a unification scheme, where instead of returning a concrete borrow kind like ty::ImmBorrow, we return a ty::InferBorrow(upvar_id) or something like that, but this would then mean that all later passes would have to check for these figments and report an error, and it just seems like more mess in the end.)