The Rust Pipeline

The usual reaction to rustc's phase list is that it looks excessive. It is not decoration: each lowering exists because a specific analysis was impossible in the form before it. Macro expansion cannot wait for types, because a macro can generate the item that defines the type. Trait resolution cannot happen on the AST, because it needs to know what the expressions *are*. Borrow checking cannot happen on a tree, because the property it proves — that a mutable borrow does not overlap another live borrow along any path — is a statement about control flow, not about nesting.

MIR is the one that changed the language. Before it existed, lifetimes were lexical: a borrow lasted to the end of its enclosing block, whether or not it was used again. That rule is checkable on a tree and it rejects an enormous amount of obviously correct code. Non-lexical lifetimes replaced it with a dataflow analysis over a control-flow graph — a borrow is live where it may still be used — and that analysis is only expressible once the program *is* a graph. The representation came first, and the language rule followed it.

The other thing MIR bought is a place to do work that LLVM should not be asked to do. Drop elaboration, which decides where destructors run and inserts the flags that track conditional drops, is a Rust semantic question with no LLVM equivalent. Const evaluation runs on MIR too. And inlining a little at MIR level, before monomorphization multiplies everything, is much cheaper than inlining the same call in every instantiation afterwards.

The borrow checker asks a question with a precise shape: at every program point, for every borrow, is that borrow still live, and does anything conflicting happen while it is? "Live" means "may still be used along some path from here", which is the definition of [[liveness-analysis]] — a backward dataflow problem over a control-flow graph. Ask it on a tree and you cannot express "along some path", so you fall back to a syntactic approximation: the borrow lives to the end of its block.

That approximation is what pre-2018 Rust used, and its failures were famous. A function that borrowed a map to look something up, then wanted to insert on the None branch, was rejected — the borrow was over in every meaningful sense but the block had not ended. Moving the check onto MIR did not make the compiler cleverer about a rule; it replaced the rule with one that could only be stated on a graph.

The consequence engineers actually feel is that borrow errors are reported in terms of paths, not lines: "value borrowed here is still borrowed when used there, because of this branch". That phrasing comes from a dataflow result, and reading it as a dataflow result — which path keeps the borrow alive — is far more productive than reading it as a rule about braces.

Macro expansion sits between parsing and HIR, which fixes what a macro can and cannot know. It operates on token trees, so it can see syntax and cannot see types: macro_rules! matches shapes, not meanings, and a macro cannot ask what type an argument has because nothing has computed one yet. That is why macro-generated code produces its errors at the expansion site, after substitution, in the same way template instantiation does in [[templates]].

Procedural macros are a larger commitment. A proc-macro crate is compiled to a dynamic library and *executed by the compiler* during the build of the crate that uses it, taking a token stream and returning one. It is an ordinary Rust program with the compiler's privileges: it can read files, open sockets and consume unbounded time, and it runs on every machine that builds the project, including CI.

Two consequences follow. Build time: derive-heavy crates spend real time running these programs, and it is attributed to the dependent crate rather than to the macro. And trust: a proc-macro dependency is code that executes on your build machine, which puts it in a different risk category from a library that merely runs in your process. See [[toolchain-trust]], and [[hermetic-compilation]] for the containment story.

Rust builds are slow for three separable reasons, and the fix differs for each. Trait resolution and inference are the frontend cost, and they grow with generic depth — deeply nested iterator chains and heavy where clauses are the expensive shapes. Monomorphization multiplies: a generic function used with twenty types becomes twenty functions, all of which LLVM must then optimize. And LLVM itself is usually the largest single term in a release build, because it is being handed the output of that multiplication.

The crate is the unit of compilation and the unit of parallelism, which cuts both ways. One large crate is one mostly serial frontend job, so splitting it into several buys parallelism and incremental rebuild granularity. But generic code from a dependency is monomorphized in *your* crate — the dependency shipped MIR, not machine code — so splitting does not move that cost anywhere, and a change to a widely used generic still touches everything.

The tooling is unusually good at telling you which of the three you have. cargo build --timings produces an HTML report of per-crate wall time and where the parallelism went; cargo llvm-lines counts LLVM IR lines per generic function and finds the monomorphization bombs; -Z self-profile breaks the frontend down by query. Guessing is unnecessary and, given how different the three fixes are, expensive.