MIR Construction and the `unpack!` Macro

# MIR construction  The lowering of [HIR] to [MIR] occurs for the following (probably incomplete) list of items: * Function and closure bodies * Initializers of `static` and `const` items * Initializers of enum discriminants * Glue and shims of any kind * Tuple struct initializer functions * Drop code (the `Drop::drop` function is not called directly) * Drop implementations of types without an explicit `Drop` implementation The lowering is triggered by calling the [`mir_built`] query. The MIR builder does not actually use the HIR but operates on the [THIR] instead, processing THIR expressions recursively. The lowering creates local variables for every argument as specified in the signature. Next, it creates local variables for every binding specified (e.g. `(a, b): (i32, String)`) produces 3 bindings, one for the argument, and two for the bindings. Next, it generates field accesses that read the fields from the argument and writes the value to the binding variable. With this initialization out of the way, the lowering triggers a recursive call to a function that generates the MIR for the body (a `Block` expression) and writes the result into the `RETURN_PLACE`. ## `unpack!` all the things Functions that generate MIR tend to fall into one of two patterns. First, if the function generates only statements, then it will take a basic block as argument onto which those statements should be appended. It can then return a result as normal: ```rust,ignore fn generate_some_mir(&mut self, block: BasicBlock) -> ResultType { ... } ``` But there are other functions that may generate new basic blocks as well. For example, lowering an expression like `if foo { 22 } else { 44 }` requires generating a small "diamond-shaped graph". In this case, the functions take a basic block where their code starts and return a (potentially) new basic block where the code generation ends. The `BlockAnd` type is used to represent this: ```rust,ignore fn generate_more_mir(&mut self, block: BasicBlock) -> BlockAnd<ResultType> { ... } ``` When you invoke these functions, it is common to have a local variable `block` that is effectively a "cursor". It represents the point at which we are adding new MIR. When you invoke `generate_more_mir`, you want to update this cursor. You can do this manually, but it's tedious: ```rust,ignore let mut block; let v = match self.generate_more_mir(..) { BlockAnd { block: new_block, value: v } => { block = new_block; v } }; ``` For this reason, we offer a macro that lets you write `let v = unpack!(block = self.generate_more_mir(...))`. It simply extracts the new block and overwrites the variable `block` that you named in the `unpack!`. ## Lowering expressions into the desired MIR There are essentially four kinds of representations one might want of an expression: * `Place` refers to a (or part of a) preexisting memory location (local, static, promoted)

This section describes the process of lowering High-Level Intermediate Representation (HIR) to Mid-Level Intermediate Representation (MIR) for various items like function bodies, static initializers, and drop implementations. It explains how the MIR builder operates on the THIR and creates local variables for arguments and bindings. The section also introduces the `unpack!` macro, which simplifies the process of updating basic block cursors when generating MIR for expressions that may create new basic blocks, such as `if` statements. Finally, it outlines the four kinds of expression representations in MIR.