@@ -85,30 +85,30 @@ Thus, only for cases when *true* random access is desired/required, raw indexing
In short, the complilation process follows:
1 Parsing input
* this processes the .rs files and produces the AST ("abstract syntax tree")
1. Parsing input
* this processes the .rs files and produces the AST ("abstract syntax tree")
* the AST is defined in syntax/ast.rs. It is intended to match the lexical syntax of the Rust language quite closely.
2 Name resolution, macro expansion, and configuration
* once parsing is complete, we process the AST recursively, resolving paths and expanding macros. This same process also processes `#[cfg]` nodes, and hence may strip things out of the AST as well.
2. Name resolution, macro expansion, and configuration
3 Lowering to HIR
* once parsing is complete, we process the AST recursively, resolving paths and expanding macros. This same process also processes `#[cfg]` nodes, and hence may strip thingsout of the AST as well.
3. Lowering to HIR
* Once name resolution completes, we convert the AST into the HIR, or "high-level IR".
* The HIR is a lightly desugared variant of the AST. It is more processed than the AST and more suitable for the analyses that follow.
4 Type-checking and subsequent analyses
4. Type-checking and subsequent analyses
* An important step in processing the HIR is to perform type checking. This process assigns types to every HIR expression, and also is responsible for resolving some "type-dependent" paths, such as field accesses (`x.f`)
5 Lowering to MIR and post-processing
5. Lowering to MIR and post-processing
Once type-checking is done, we can lower the HIR into MIR ("middle IR"), which is a very desugared version of Rust.
* Once type-checking is done, we can lower the HIR into MIR ("middle IR"), which is a very desugared version of Rust.
Here is where the borrow checking is done!!!!
6 Translation to LLVM and LLVM optimizations
6. Translation to LLVM and LLVM optimizations
From MIR, we can produce LLVM IR.
* From MIR, we can produce LLVM IR.
LLVM then runs its various optimizations, which produces a number of .o files (one for each "codegen unit").
