Skip to content
La3 Docs
Browse docs

Compiler Overview

From parse trees to native binaries, and why MIR exists as a separate lowering layer.

Pipeline

The current and planned pipeline is explicit: AST, type and borrow checking, HIR, MIR, LLVM, object, link.

The front end is already more than a parser. It resolves names, infers types, checks ownership, and feeds the interpreter. The native compiler reuses that correctness boundary rather than re-implementing it from scratch.

  • AST is the parsed surface tree.
  • HIR is typed and desugared.
  • MIR is the control-flow lowering layer that owns the hard transformations.
  • LLVM is the final codegen target, kept as thin as possible.

Interpreter oracle

The interpreter is not a temporary prototype; it is the behavioural oracle for the native backend.

  • It keeps semantic drift visible.
  • It gives the compiler a stable target to compare against.
  • It makes differential testing practical at every phase.

Runtime

The runtime crate is the native support library the compiled programs will link against.

Owned heap types, drop glue, string handling, collections, and small stdlib shims live here instead of in the generated code. That keeps codegen simpler and gives the compiler a stable ABI target.

  • It is owned-memory based, not ARC-based.
  • It needs to stay Miri-clean.
  • The runtime becomes the place where by-value semantics are made concrete for native code.

Milestones

The compiler plan is phase driven, with the current work split across type checking, ownership, HIR, MIR, and backend stages.

  • Phase 1 hardens types and ownership.
  • Phase 2 lowers to HIR and removes surface sugar.
  • Phase 3 builds MIR and its lowerings.
  • Later phases cover runtime-backed values, codegen, and dynamic stdlib design.