Cx语言301行代码截胡：编译器团队把循环依赖检测做成了"体检报

一个编译器项目把后端架构推倒重来，同时塞进了一套能画依赖图谱的模块解析器。这不是路线图上的远期规划，是3月24日到25日两天内连续合进主线的代码。

IR后端重构和模块解析器两条线同时撞线，让Cx语言在"能跑"和"好用"之间跨了一步。

对写编译器的团队来说，AST（抽象语法树）到IR（中间表示）的切换是单行道。一旦Backend trait的接口从&Program改成&IrModule，所有后端代码必须跟着改。Cranelift和LLVM两个后端已经同步迁移，没有回头路。

这次合并的PR #19包含四个提交，标记为Phase 0.5。版本号带小数点通常意味着还没完，但"0.5"的命名暗示架构师心里清楚：真正的难关是接下来的循环、结构体这些复杂结构怎么降层。

调试工具的补齐比功能本身更能说明问题。新增的--backend=validate模式可以跑完IR降层和校验，不碰任何代码生成后端。--debug-trace则会把每条IR指令在降层时的输出打印出来。

这些工具的存在，说明团队已经被IR管道的调试折磨过。自动dump IR模块的功能，用项目成员的话说，能在校验失败时"省掉很多头痛"。

301行的"体检科"：模块解析器做了什么

submain分支的resolver.rs用301行代码解决了三个问题：依赖图谱怎么画、循环引用怎么抓、文件加载按什么顺序。

核心数据结构是ModuleId、ImportEdge、ResolvedFile、ResolvedProgram。相对路径./被显式支持，递归深度硬上限100层。std/开头的标准库导入在v0.1版本会直接报错，不给模糊处理。

解析器现在已经串进main.rs的工作流，卡在语法分析和语义分析之间。单文件程序无感知，多文件程序遇到缺失导入时会给出明确错误，而不是之前的神秘崩溃。

测试用例t65和t66在submain上被标记为expected_fail，这是故意的——它们在main分支上会因为缺乏有效的导入解析而错误地通过。

这种"让测试失败"的操作，反而证明了解析器的准确性。就像体检科把指标标红，不是机器坏了，是之前的"正常"是漏诊。

ExportTable：为跨文件符号埋下的桩

semantic_types.rs新增的ExportTable结构体，给函数、结构体、常量、枚举各准备了一张映射表。公开符号在解析后的模块里填充进导出表，导入方就能用alias.symbol的格式引用。

这个设计为未来功能留了口子：死代码消除需要知道哪些符号被谁依赖，循环引用检测需要遍历ImportEdge构成的图。现在建的依赖图谱，以后可以复用。

架构师选择"多花时间建图"而不是简单加载文件，是因为稳定的模块ID和导入边在后续优化里不可替代。可能的../路径遍历也被显式处理，虽然原文截断，但意图明显：路径安全要防住。

两条线交汇后的产品意味

IR后端和模块解析器看似不相关，实则共享同一种设计哲学：先把基础设施打实，再往上堆功能。AST到IR的切换堵死了走捷径的可能，依赖图谱的构建拒绝了"先跑起来再说"的侥幸。

对Cx语言的用户来说，这些变化暂时 invisible。但编译器团队正在把"能跑"和"跑得对"之间的鸿沟，用代码而不是文档填上。

--backend=validate和--debug-trace的存在，暗示开发者体验已经被纳入技术债务的偿还计划。模块解析器的错误信息从"神秘崩溃"变成"明确提示"，是产品经理会点赞的那种改进。

301行代码的resolver.rs没有炫技，但把循环依赖检测、拓扑排序、路径校验这些脏活累活打包成了一个可测试的单元。ExportTable的预留设计，说明作者已经看到三个月后的需求。

一个还在0.x阶段的语言项目，开始表现出成熟产品的特征：不是功能列表的膨胀，是故障模式的收敛。

当t65和t66测试用例从"错误通过"变成"预期失败"，团队实际上在重新定义"正确"的基准线。这种自我修正的能力，比任何路线图都更能预测项目的寿命。

IR管道的调试工具、模块解析器的错误提示、ExportTable的预留接口——这三件事指向同一个问题：当Cx语言的用户规模从"核心团队"扩展到"早期采用者"时，编译器能不能给出足够的信息让他们自助排障？

答案正在代码里逐步硬化。不是承诺，是已经合并的提交。

下一个会被标记为expected_fail的测试会是什么？循环体内的IR校验，还是跨 crate 的符号解析？