Carbon toolchain設計

Compiler pipeline

公式toolchain architectureは次の明確なphaseに分かれます。

flowchart LR
  A[SourceBuffer] --> B[Lex tokens]
  B --> C[Parse tree]
  C --> D[Check SemIR]
  D --> E[Lower LLVM module]
  E --> F[CodeGen object]

Driverがcommandと全体flowを結び、Diagnosticsが各phaseのerrorを出します。carbon compileは最終的にobject fileを作り、carbon linkがexecutableを作ります。

Phase	Input	Output	主なfailure
Source	file	`SourceBuffer`	I/O、encoding
Lex	source buffer	`Lex::TokenizedBuffer`	invalid token/literal
Parse	tokens	`Parse::Tree`	grammar、delimiter
Check	parse tree	`SemIR::File`	name/type/impl resolution
Lower	SemIR	LLVM Module	representation/codegen preparation
CodeGen	LLVM Module	object file	target/backend
Link	object files/libs	executable	missing symbol/runtime/library

compile失敗を一括りにせず、どのphaseかを診断します。Carbon contributorになる場合、small featureがtokens、parse node、SemIR、lowering、diagnostic、file testsのどこへ影響するかを先にmapします。

各phaseはcallbackで次phaseを直接駆動せず、明示的なoutput structureを作ります。input/output contractが明確で、localityと理解しやすさを狙います。

tree nodeなどを個別heap object/pointer graphとして持つより、vectorに密に置きsmall indexで参照します。

期待する効果:

tradeoff:

parserはrecursive callよりexplicit state stackとloopを重視します。悪意ある/極端に深いsourceでもC++ call stack limitへ依存しにくくします。

SemIRはsyntax treeとLLVM IRの間にあるsemantic representationです。name resolution、type information、generic semanticsなど、LLVM IRに直接落とすには高水準すぎる意味を保持します。

学習順:

CLI optionはnightlyで変化するため、この教材では固定commandを推測しません。必ずpinned binaryのcarbon helpをsource of truthにします。

最初のcontribution候補はparser crash修正より、既存issueに紐づくdiagnosticまたはfile test改善が安全です。