Inferences and Upvars in the Rust Compiler

Here, `x` is directly moved into the closure and the access to it will not be permitted after the closure. ## Inferences in the compiler Now let's dive into rustc code and see how all these inferences are done by the compiler. Let's start with defining a term that we will be using quite a bit in the rest of the discussion - *upvar*. An **upvar** is a variable that is local to the function where the closure is defined. So, in the above examples, **x** will be an upvar to the closure. They are also sometimes referred to as the *free variables* meaning they are not bound to the context of the closure. [`compiler/rustc_passes/src/upvars.rs`][upvars] defines a query called *upvars_mentioned* for this purpose. Other than lazy invocation, one other thing that distinguishes a closure from a normal function is that it can use the upvars. It borrows these upvars from its surrounding context; therefore the compiler has to determine the upvar's borrow type. The compiler starts with assigning an immutable borrow type and lowers the restriction (that is, changes it from **immutable** to **mutable** to **move**) as needed, based on the usage. In the Example 1 above, the closure only uses the variable for printing but does not modify it in any way and therefore, in the `mir_dump`, we find the borrow type for the upvar `x` to be immutable. In example 2, however, the closure modifies `x` and increments it by some value. Because of this mutation, the compiler, which started off assigning `x` as an immutable reference type, has to adjust it as a mutable reference. Likewise in the third example, the closure drops the vector and therefore this requires the variable `x` to be moved into the closure. Depending on the borrow kind, the closure has to implement the appropriate trait: `Fn` trait for immutable borrow, `FnMut` for mutable borrow, and `FnOnce` for move semantics. Most of the code related to the closure is in the [`compiler/rustc_hir_typeck/src/upvar.rs`][upvar] file and the data structures are declared in the file [`compiler/rustc_middle/src/ty/mod.rs`][ty]. Before we go any further, let's discuss how we can examine the flow of control through the rustc codebase. For closures specifically, set the `RUSTC_LOG` env variable as below and collect the output in a file: ```console > RUSTC_LOG=rustc_hir_typeck::upvar rustc +stage1 -Z dump-mir=all \ <.rs file to compile> 2> <file where the output will be dumped>

The text discusses how the rustc compiler infers closure behavior, particularly focusing on 'upvars' (variables from the surrounding context used by the closure). It explains that the compiler starts by assuming an immutable borrow for upvars and then loosens this restriction to mutable or move based on how the closure uses the variable. Examples are given to illustrate how different types of access (reading, mutating, dropping) lead to different capture types. The closure must implement the appropriate trait, `Fn`, `FnMut`, or `FnOnce`, depending on the borrow kind. Relevant source code files are mentioned, and instructions are given on how to use the `RUSTC_LOG` environment variable to trace the closure analysis in the compiler.