Jon Ross-Perkins
9704dc670e
The main direction of this change is the edits to `destroy.carbon` (matching in both prelude and min_prelude). Previously there was a no-op blanket impl for `Destroy`, which hid all missing implementations of `Destroy`. This does a few things: - Sets up builtin aggregate destruction for struct and tuple types as before, but also adds C++ class types and array types to the same handling. (all as a TODO for actual implementation) - Also maybe-unformed destruction, for now at least. (there's a chance I may try a different approach on this, but the impl lookup wasn't working as I'd hope in order to write it in code) - Adds handlers for simple things that are easy to do in code: `type`, `bool`, pointers. (because these are no-op destruction) - Redirect `const T` destruction to `T` destruction. This leaves as future issues: - `partial T` destruction. (this can't be done similar to `const` because it only works for non-`final` class types; I think `class` definitions should just generate what's needed) - Destruction of other prelude-provided types. (will probably come up as we implement class destruction, that the adapted builtin type doesn't implement `Destroy` -- but may end up special-casing that in a way that moots it) This moves the `&` operator from `facet_types.carbon` to `convert.carbon` because more things need to handle type and now that we're getting separate copy and destroy interfaces. It should be low-cost (an interface and builtin) so hopefully this is the right balance for complexity and re-use. A few tests are also edited in order to focus them more on what they intend to test, and avoid a `Destroy` dependency.
Toolchain architecture
Table of contents
Goals
The toolchain represents the production portion of Carbon. At a high level, the toolchain's top priorities are:
- Correctness.
- Quality of generated code, including performance.
- Compilation performance.
- Quality of diagnostics for incorrect or questionable code.
TODO: Add an expanded document that details the goals and priorities and link to it here.
High-level architecture
The main components are:
-
Driver: Provides commands and ties together compilation flow.
-
Diagnostics: Produces diagnostic output.
-
Compilation flow:
- Source: Load the file into a SourceBuffer.
- Lex: Transform a SourceBuffer into a Lex::TokenizedBuffer.
- Parse: Transform a TokenizedBuffer into a Parse::Tree.
- Check: Transform a Tree to produce SemIR::File.
- Lower: Transform the SemIR to an LLVM Module.
- CodeGen: Transform the LLVM Module into an Object File.
Design patterns
A few common design patterns are:
-
Distinct steps: Each step of processing produces an output structure, avoiding callbacks passing data between structures.
-
For example, the parser takes a
Lex::TokenizedBufferas input and produces aParse::Treeas output. -
Performance: It should yield better locality versus a callback approach.
-
Understandability: Each step has a clear input and output, versus callbacks which obscure the flow of data.
-
-
Vectorized storage: Data is stored in vectors and flyweights are passed around, avoiding more typical heap allocation with pointers.
-
For example, the parse tree is stored as a
llvm::SmallVector<Parse::Tree::NodeImpl>indexed byParse::Nodewhich wraps anint32_t. -
Performance: Vectorization both minimizes memory allocation overhead and enables better read caching because adjacent entries will be cached together.
-
-
Iterative processing: We rely on state stacks and iterative loops for parsing, avoiding recursive function calls.
-
For example, the parser has a
Parse::Stateenum tracked instate_stack_, and loops inParse::Tree::Parse. -
Scalability: Complex code must not cause recursion issues. We have experience in Clang seeing stack frame recursion limits being hit in unexpected ways, and non-recursive approaches largely avoid that risk.
-
See also Idioms for abbreviations and more implementation techniques.
Adding features
We have a walkthrough for adding features.
Videos
Talks
These talks are focused on implementation details of the toolchain, and can be helpful for learning how the toolchain internals work.
2025
Implementation walkthroughs
These are recordings of implementing PRs.