1. 项目概述为什么用C20重写一个C编译器在编译器领域用C来写一个C编译器这事儿听起来有点“用高射炮打蚊子”的意味。毕竟经典的GCC和Clang/LLVM生态已经非常成熟尤其是Clang本身也是用C写的。那为什么还要有cci这个项目它的价值在哪里我花了不少时间研究这个项目发现它的核心目标并非要取代谁而更像是一个现代C语言特性的“试验场”和“最佳实践展示台”。它瞄准的是C17标准试图用C20这一最新语言标准提供的强大工具来构建一个清晰、模块化、易于理解和学习的编译器前端。这解决了几个痛点对于学习者GCC和Clang的代码库庞大且历史包袱重初学者容易迷失在宏、特定数据结构和历史代码风格中。对于C开发者C20引入了模块Modules、概念Concepts、协程Coroutines、范围Ranges等重磅特性但缺乏一个中等规模、结构完整的现实项目来展示如何将这些特性有机地结合起来解决复杂问题。cci项目正好填补了这个空白。它用std::variant和std::optional优雅地处理语法树AST用概念约束模板元编程用模块组织代码结构甚至尝试用范围视图来简化编译器内部的某些遍历逻辑。通过剖析cci你不仅能理解编译器前端的基本构造——从词法分析、语法分析到语义检查和中间代码生成更能直观地看到现代C如何让这类复杂系统的代码变得更安全、更简洁、更具表达力。这非常适合有一定C基础想深入理解语言特性和编译器原理的开发者。2. 核心架构与设计哲学cci项目的架构清晰地遵循了经典编译器的阶段划分但在实现细节上充满了现代C的气息。它的设计哲学可以概括为利用强类型系统和现代抽象来提升代码的可靠性和可读性同时保持各个阶段的相对独立和清晰的接口。2.1 模块化设计告别头文件依赖噩梦这是C20带给cci最直观的改变。传统的C/C项目严重依赖头文件#include和前置声明这导致了漫长的编译时间、复杂的依赖管理和容易出现的循环依赖问题。cci充分利用了C20的模块特性。在cci中你不会看到成堆的.hpp文件。取而代之的是模块接口文件.ixx或.cppm。例如词法分析器可能被定义在一个名为lexer.ixx的模块中// lexer.ixx export module cci.lexer; import string_view; import vector; import cstdint; export namespace cci { enum class TokenKind : std::uint8_t { Identifier, IntegerLiteral, Plus, Minus, // ... 其他Token类型 Eof }; struct Token { TokenKind kind; std::string_view text; std::size_t line; std::size_t column; }; export class Lexer { public: explicit Lexer(std::string_view source); Token nextToken(); // ... private: std::string_view source_; std::size_t pos_{0}; std::size_t line_{1}; std::size_t column_{1}; // ... }; }然后在语法分析器Parser模块中你可以清晰地导入它// parser.ixx export module cci.parser; import cci.lexer; // 清晰、高效的导入 import memory; import variant;这种方式的优势非常明显编译加速模块接口只编译一次之后以二进制形式存储避免了头文件的重复解析。语义清晰import语句明确指明了依赖关系代码结构一目了然。隔离性更好模块内部实现细节非导出部分对外完全不可见实现了更好的封装。实操心得在迁移旧项目到模块时最大的挑战是理清原有的依赖图。建议从底层、依赖最少的模块开始如基础类型定义、Token定义逐步向上构建。使用像CMake 3.28这样的构建工具它们已经提供了对C20模块的良好支持。2.2 强类型AST利用std::variant和继承的双重优势抽象语法树AST是编译器的核心数据结构。传统实现要么使用继承层次结构基类Expr派生类BinaryExpr,CallExpr等配合大量的动态类型转换dynamic_cast要么使用标签联合tagged union但类型安全性差。cci采用了现代C的“访问者模式std::variant”组合拳实现了既安全又高效的AST表示。首先定义所有表达式节点类型// ast.ixx export module cci.ast; import variant; import memory; import string; export namespace cci::ast { struct Identifier { std::string name; }; struct IntegerLiteral { int64_t value; }; struct BinaryExpr; struct CallExpr; // ... 其他节点类型定义 // 前向声明和递归包装 using Expr std::variant Identifier, IntegerLiteral, std::unique_ptrBinaryExpr, std::unique_ptrCallExpr // ... ; struct BinaryExpr { Expr left; enum class Op { Add, Sub, Mul, Div } op; Expr right; }; struct CallExpr { Expr callee; std::vectorExpr arguments; }; }这里Expr被定义为一个std::variant它可以持有多种具体的节点类型。对于需要递归引用的类型如BinaryExpr包含左右子表达式使用std::unique_ptr进行包装这是处理递归变体的常用技巧。这种设计的好处是类型安全你无法错误地访问一个IntegerLiteral的op字段编译器会在编译期检查。高效的内存布局std::variant通常使用类似联合体的存储比多态继承的虚表指针开销更小内存更紧凑。模式匹配友好C23引入了真正的模式匹配但即使在C20结合std::visit也能写出清晰的访问逻辑。2.3 概念Concepts约束让模板错误信息更友好编译器中有大量操作AST的泛型算法比如遍历、查找、变换。在C20之前这些算法通常使用SFINAE或标签分发错误信息晦涩难懂。cci大量使用概念来约束模板参数使得接口更清晰错误信息更直接。例如一个用于检查表达式是否包含某个标识符的遍历器// traverser.ixx export module cci.traverser; import cci.ast; import concepts; export namespace cci { // 定义一个概念要求类型T必须能够被std::visit访问 templatetypename T concept Visitable requires(T v, const ast::Expr expr) { { std::visit(std::forwardT(v), expr) } - std::same_asvoid; }; // 使用概念约束的查找函数 templateVisitable Visitor bool contains_identifier(const ast::Expr expr, Visitor vis) { // ... 遍历逻辑 std::visit(std::forwardVisitor(vis), expr); // ... return found; } }当用户传递一个不符合Visitable概念的对象时编译器会直接在调用点报出清晰易懂的错误指出具体哪个约束不满足而不是在模板实例化的深层抛出几十行令人困惑的错误。3. 关键组件实现深度解析3.1 词法分析器Lexer从源码到Token流词法分析是编译器的第一步负责将字符流转换为有意义的Token流。cci的Lexer实现体现了现代C对性能和清晰度的兼顾。核心状态与扫描Lexer内部通常维护一个指向源码字符串的视图std::string_view和一个当前位置指针。nextToken()方法是核心它通过一个大的switch或查找表来识别字符。Token Lexer::nextToken() { skipWhitespace(); // 跳过空白字符 if (pos_ source_.length()) { return {TokenKind::Eof, , line_, column_}; } char current source_[pos_]; column_; // 识别标识符和关键字 if (isAlpha(current) || current _) { return scanIdentifierOrKeyword(); } // 识别数字字面量 if (isDigit(current)) { return scanNumber(); } // 识别操作符和标点 switch (current) { case : pos_; if (peek() ) { // 看下一个字符可能是 pos_; column_; return {TokenKind::Increment, , line_, column_-2}; } return {TokenKind::Plus, , line_, column_-1}; case : pos_; if (peek() ) { // // ... 类似处理 } return {TokenKind::Assign, , line_, column_-1}; // ... 处理其他单字符或双字符操作符 case : return scanStringLiteral(); case \: return scanCharLiteral(); default: // 无法识别的字符报告错误 reportError(Unexpected character); pos_; return {TokenKind::Unknown, std::string_view(current, 1), line_, column_-1}; } }scanIdentifierOrKeyword函数在识别出一串字母数字后需要判断它是用户定义的标识符还是语言关键字。这里通常使用一个std::unordered_mapstd::string_view, TokenKind作为关键字表进行快速查找。注意事项处理数字字面量尤其是浮点数、不同进制和字符串字面量转义字符、多行字符串是词法分析中的复杂部分需要仔细处理。cci的代码中这部分逻辑通常独立成函数并且有完善的错误处理如报告数字溢出、未终止的字符串。3.2 语法分析器Parser递归下降与错误恢复cci的语法分析器采用了经典的递归下降分析法。这种方法与C语言的语法规则高度对应代码可读性极强。每个非终结符如expression,statement,declaration都对应一个解析函数。表达式解析示例以解析加法乘法表达式为例假设优先级乘法高于加法。// 解析基础因子数字、标识符、括号表达式 std::optionalExpr Parser::parsePrimary() { auto tok lexer_.currentToken(); switch (tok.kind) { case TokenKind::IntegerLiteral: lexer_.consumeToken(); return ast::IntegerLiteral{std::stoll(std::string(tok.text))}; case TokenKind::Identifier: lexer_.consumeToken(); return ast::Identifier{std::string(tok.text)}; case TokenKind::LeftParen: { lexer_.consumeToken(); // 吃掉( auto expr parseExpression(); if (!expr) return std::nullopt; if (!expect(TokenKind::RightParen)) { // 期待) // 错误恢复可以尝试同步到下一个语句开始处 synchronize(); return std::nullopt; } return expr; } default: reportError(Expected primary expression); return std::nullopt; } } // 解析乘法表达式 std::optionalExpr Parser::parseMultiplicative() { auto left parsePrimary(); if (!left) return std::nullopt; while (true) { auto opTok lexer_.currentToken(); if (opTok.kind TokenKind::Star || opTok.kind TokenKind::Slash) { lexer_.consumeToken(); auto right parsePrimary(); if (!right) { reportError(Expected expression after operator); // 错误恢复可以假设右边是一个缺失的表达式继续解析 right ast::IntegerLiteral{0}; // 插入一个“错误”节点 } // 构建AST节点 left std::make_uniqueast::BinaryExpr( std::move(*left), opTok.kind TokenKind::Star ? ast::BinaryExpr::Op::Mul : ast::BinaryExpr::Op::Div, std::move(*right) ); } else { break; } } return left; } // 解析加法表达式调用乘法表达式 std::optionalExpr Parser::parseAdditive() { auto left parseMultiplicative(); if (!left) return std::nullopt; while (true) { auto opTok lexer_.currentToken(); if (opTok.kind TokenKind::Plus || opTok.kind TokenKind::Minus) { lexer_.consumeToken(); auto right parseMultiplicative(); // 注意右边是乘法表达式保证了优先级 if (!right) { // ... 错误处理 } left std::make_uniqueast::BinaryExpr( std::move(*left), opTok.kind TokenKind::Plus ? ast::BinaryExpr::Op::Add : ast::BinaryExpr::Op::Sub, std::move(*right) ); } else { break; } } return left; } // parseExpression 可能是 parseAdditive 的别名或简单封装错误恢复策略一个健壮的编译器不能因为一个语法错误就停止。递归下降分析器中错误恢复是关键。常见的策略包括恐慌模式Panic Mode当遇到错误时丢弃输入Token直到遇到一个“同步点”如分号;、右大括号}等语句或块的边界然后继续解析。上面的synchronize()函数就是干这个的。错误产生式在语法规则中显式地加入错误处理。例如在parsePrimary中当期待表达式却遇到其他Token时可以报告错误并返回一个特殊的“错误表达式”节点让解析得以继续便于收集多个错误。预期Token匹配expect(TokenKind)函数是常用辅助函数它检查当前Token是否匹配预期不匹配则报告错误并可能尝试恢复。3.3 语义分析类型检查与符号表管理语法分析只保证代码结构符合语法语义分析则要保证代码“有意义”。对于C语言这主要包括类型检查和符号表管理。符号表Symbol Table这是一个层次化的数据结构用于记录标识符变量名、函数名、类型名的信息类型、作用域、内存位置等。cci可能使用一个栈或链表结构来表示嵌套的作用域。class SymbolTable { struct Scope { std::unordered_mapstd::string, Symbol symbols; Scope* parent; }; Scope* currentScope_ nullptr; public: void enterScope() { auto newScope std::make_uniqueScope(); newScope-parent currentScope_; currentScope_ newScope.get(); scopes_.push_back(std::move(newScope)); } void leaveScope() { if (currentScope_) { currentScope_ currentScope_-parent; } } bool insert(const std::string name, Symbol sym) { if (currentScope_-symbols.count(name)) { return false; // 重复定义 } currentScope_-symbols[name] std::move(sym); return true; } std::optionalSymbol lookup(const std::string name) const { for (auto* scope currentScope_; scope ! nullptr; scope scope-parent) { auto it scope-symbols.find(name); if (it ! scope-symbols.end()) { return it-second; } } return std::nullopt; } private: std::vectorstd::unique_ptrScope scopes_; };类型检查在遍历AST时对每个表达式节点推断并验证其类型。例如对于二元操作a b需要检查a和b的类型是否兼容都是算术类型或都是指针且满足特定条件等然后推断出结果类型。对于函数调用需要检查实参类型与形参类型是否匹配。cci会为AST节点附加类型信息这些信息在后续的中间代码生成阶段至关重要。3.4 中间代码生成从AST到三地址码或LLVM IR语义分析之后编译器需要将高级的AST转换为更低级、更接近机器、且与平台无关的中间表示IR。cci可能选择生成自定义的三地址码或者直接生成LLVM IR。生成自定义三地址码这是一种更简单的选择便于教学和理解。三地址码的基本形式是x y op z。遍历AST时为每个表达式生成临时的中间变量。// 一个简化的中间代码生成访问者 class IRGenerator { std::vectorInstruction instructions_; int tempCounter_{0}; std::string newTemp() { return %t std::to_string(tempCounter_); } public: void visit(const ast::BinaryExpr expr) { // 递归生成左右操作数的代码 visit(*expr.left); std::string leftTemp lastTemp_; visit(*expr.right); std::string rightTemp lastTemp_; // 生成当前操作的指令 std::string resultTemp newTemp(); Instruction instr; instr.op getOpcode(expr.op); // 将AST操作符映射为IR操作码 instr.dest resultTemp; instr.src1 leftTemp; instr.src2 rightTemp; instructions_.push_back(instr); lastTemp_ resultTemp; } // ... 其他visit方法 };生成LLVM IR如果cci的目标是生成可优化、可执行的高质量代码集成LLVM是更专业的选择。LLVM提供了完善的C API来构建IR。这种方式下cci的代码生成器会调用LLVM IRBuilder等API来创建指令、函数和模块。// 使用LLVM C API的示例片段 llvm::Value* IRGenerator::visit(const ast::BinaryExpr expr, llvm::IRBuilder builder) { llvm::Value* L visit(*expr.left, builder); llvm::Value* R visit(*expr.right, builder); switch (expr.op) { case ast::BinaryExpr::Op::Add: return builder.CreateAdd(L, R, addtmp); case ast::BinaryExpr::Op::Sub: return builder.CreateSub(L, R, subtmp); // ... 其他操作 default: llvm_unreachable(Unknown binary operator); } }选择LLVM意味着将代码优化和平台代码生成的重任交给了这个久经考验的框架而cci可以专注于前端语法、语义的正确性。4. 构建、测试与调试实践一个完整的编译器项目离不开坚实的构建系统和测试套件。cci作为现代C项目其工程实践也值得借鉴。4.1 使用CMake构建CMake是现代C项目的事实标准构建系统。cci的CMakeLists.txt会配置C20标准处理模块依赖并定义可执行文件、库和测试目标。cmake_minimum_required(VERSION 3.26) # 需要支持C20模块 project(cci LANGUAGES CXX) set(CMAKE_CXX_STANDARD 20) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) # 启用模块支持MSVC和Clang/GCC方式不同 if (MSVC) add_compile_options(/experimental:module /std:clatest) else() # 对于GCC/Clang需要指定模块映射等更复杂 add_compile_options(-fmodules-ts -stdc20) endif() # 定义库 add_library(cci_ast ast.ixx) add_library(cci_lexer lexer.ixx) add_library(cci_parser parser.ixx) # ... 设置模块依赖关系例如parser依赖lexer和ast target_link_libraries(cci_parser PUBLIC cci_lexer cci_ast) # 定义编译器可执行文件 add_executable(cci driver.cpp) target_link_libraries(cci PRIVATE cci_parser cci_ast ...) # 添加单元测试 enable_testing() add_executable(test_lexer test_lexer.cpp) target_link_libraries(test_lexer PRIVATE cci_lexer) add_test(NAME lexer COMMAND test_lexer)4.2 单元测试与集成测试编译器必须高度可靠。cci应该包含针对各阶段的单元测试。词法分析测试提供源代码片段验证输出的Token序列是否正确。语法分析测试提供合法和非法的代码验证AST构建是否正确错误是否被恰当报告。语义分析测试测试类型检查、符号解析是否正确。代码生成测试对于简单的输入程序验证生成的IR或最终执行结果是否符合预期。可以使用Google Test、Catch2等测试框架。测试驱动开发TDD在编译器开发中尤其有效因为编译器的行为有非常明确的规范语言标准。4.3 调试技巧调试编译器有其特殊性因为你要调试的是一个正在处理代码的程序。打印AST实现一个AST打印器Pretty Printer将内存中的AST以缩进格式输出到控制台这是最直观的调试手段。跟踪Token流在Lexer中设置调试标志打印每一个识别出的Token。使用LLVM的调试工具如果生成LLVM IR可以使用llvm::outs()打印IR使用lliLLVM解释器直接执行IR来验证逻辑。隔离测试将出错的代码片段提取出来构造一个最小的、可复现的测试用例然后单步调试编译器处理这个用例的过程。5. 常见挑战与解决方案实录在实际动手实现或学习cci这类项目时你会遇到一些典型的“坑”。这里记录了一些常见问题及其解决思路。5.1 模块依赖与循环引用问题在模块化设计中很容易出现模块A导入模块B模块B又导入模块A的循环依赖这是不允许的。解决方案重构设计提取公共部分到第三个基础模块C让A和B都导入C但彼此不直接导入。使用前置声明模块C20允许export module A;后跟import B;但B不能导入A。需要仔细规划模块层次通常是自底向上基础类型和工具 - 词法分析 - 语法分析 - 语义分析 - 代码生成。将实现与接口分离对于大型模块可以考虑将实现细节放在一个单独的“实现分区”中接口分区只导入必要的声明。5.2 递归变体Recursive Variant的内存管理问题在AST定义中Expr变体包含了std::unique_ptrBinaryExpr而BinaryExpr又包含Expr成员形成了递归。std::variant的析构需要知道其持有类型的完整定义这在递归场景下可能引发编译问题。解决方案使用std::unique_ptr包装递归类型正如cci所做这是标准且有效的方法。它打破了类型的直接循环依赖因为指针类型是完整的。确保类型在变体定义前声明BinaryExpr和CallExpr等类型必须在Expr变体别名定义之前进行前向声明。变体定义中使用的必须是已完全定义或前向声明后以指针形式使用的类型。自定义分配器对于性能极端敏感的场景可以考虑使用自定义分配器或内存池来分配AST节点减少unique_ptr的开销但这大大增加了复杂性。5.3 错误信息的友好性问题编译器给出的错误信息如果只是“语法错误在第5行”对用户帮助不大。解决方案记录源码位置在Token和AST节点中保存行号、列号信息。提供上下文在报告错误时打印出错行附近的一小段源码并用^标记出错位置。error: expected ; after expression 5 | int x 10 | ^错误恢复与多错误报告如之前所述实现良好的错误恢复机制以便在一次编译中报告尽可能多的错误而不是遇到第一个错误就停止。建议对于常见错误如写成可以给出修改建议。5.4 处理复杂的声明符和类型系统问题C语言的声明语法非常复杂如int (*(*fp)(int))[10];类型系统包含基本类型、指针、数组、函数、结构体、联合体等它们的组合和等价规则处理起来很棘手。解决方案遵循标准规范仔细阅读C语言标准如C17中关于声明和类型的章节。使用“螺旋法则”或“从内到外”的解析方法来理解复杂声明。抽象类型表示设计一个能表示所有C类型的内部数据结构Type类。这个结构需要能够递归地表示复合类型。struct Type { enum class Kind { Int, Pointer, Array, Function, Struct } kind; std::unique_ptrType base; // 用于指针、数组 std::size_t arraySize; // 用于数组 std::vectorType paramTypes; // 用于函数 std::string name; // 用于结构体/自定义类型 // ... };类型等价性比较实现一个函数来比较两个类型是否等价。对于结构体可能需要处理不完全类型和向前声明。5.5 与现有构建系统和编辑器的集成问题C20模块对现有工具链特别是CMake和IDE的支持仍在完善中。解决方案CMake使用最新版本的CMake3.26并关注其对不同编译器MSVC, Clang, GCC模块支持的更新。对于GCC/Clang可能需要手动编写模块映射文件.gcm相关。IDE/编辑器Visual Studio 2022 17.8 对MSVC的模块支持较好。对于Clang/CLion需要配置正确的CMake Profile和编译器标志。这是一个快速发展的领域需要查阅编译器和你所用IDE的最新文档。备选方案在项目早期或教育目的下如果不希望被模块的构建复杂性困扰可以暂时退回到使用传统的头文件方式组织代码但用命名空间和清晰的目录结构来模拟模块化。等工具链更成熟后再迁移。通过cci这个项目你收获的远不止一个能编译C程序的工具。它是一扇窗口让你看到如何将C20的抽象能力应用于一个经典的、复杂的系统编程问题。从模块化的项目管理到利用变体和访问者模式设计安全的数据结构再到用概念约束泛型代码每一个环节都是对现代C理念的一次深刻实践。我自己的体会是实现编译器前端的过程是对编程语言本身理解的一次升华你会开始以语言设计者的视角看待代码中的分号、括号和关键字。虽然cci可能不会用于生产环境去编译Linux内核但它作为学习现代C和编译器原理的桥梁其价值是独一无二的。如果你正在寻找一个项目来巩固C20特性并挑战自己的系统编程能力深入剖析甚至参与贡献cci会是一个非常棒的选择。