17.5 维护大型编译器代码库

一款优秀的工业级编译器可能会安稳生存长达几十年，而在那期间它所编译的源语言、后端目标芯片平台、维护的研发团队以及编译构建系统全都会经历高频的更迭和洗礼。因此，代码库的长久可维护性，始终肇始于其内部高度清晰的编译阶段边界（phase boundaries）与极其严格的数据所有权（data ownership）约束。例如，词法语法解析器（Parser）绝对不能贪图方便直接去强行读取寄存器分配器（register allocator）的局部状态；代码优化器（Optimizer）也绝不容许将修改全局符号表（global symbol table）等高风险行为作为某种隐含的内部副作用进行偷渡。编译流程中的每一个独立阶段（phases）都应当极为明确、诚实地宣告：自己在这个位置接受哪些必要的输入不变量（input invariants）、保障产出哪些格式合规的输出不变量（output invariants）、可能在何时发射并生成诊断报告，以及在遭遇重大故障无法继续时应当如何自若地撤离。

引入在学术上被广泛推崇的不可变（Immutable）或持久化中间表示（persistent IR）能极大地在底层简化内存所有权与高速缓存（cache）的推理复杂度，但在特定的分析遍（passes）内部采用轻度、受控的变量状态突变（mutation）在工业界实践中也完全是高度合理的折中设计。而无论我们最终做出何种架构选择，都必须强硬规定：一切对 IR 的生成或改动必须强制通过一组集中维护使用-定义链（use-def chain）、控制流图控制边（control-flow edge）、源码物理位置（source location）与静态分析事实失效机制（analysis invalidation）的中央安全访问 API 来集中完成，绝不容许手写侵入。编译各阶段所需的安全服务一律应当通过显式的上下文对象（context）参数进行清晰传递，而绝不应该投机取巧地去高度依赖同进程全局瞬时变量（process-wide globals）。任何隐秘的目标平台（target）属性设置、全局隐藏的当前解析文件指针、以及通用的字符串常量压缩池（intern pool），都会在未来的多核并行多线程编译与高难度的确定性测试构建中让系统的稳健性变得不堪一击。

代码库底层的树状引用依赖方向应当始终坚定不移地指向体积极小、且架构高度稳定的基础抽象接口。例如，高级的语言前端（Frontend）仅需要降解（lower）到一组完全共享的基础中间表示 IR 接口，底层的各物理厂商芯片 Target 实现对应的后端物理契约（backend contract），最终由全局总线调度（orchestration）层来将各大独立的 passes 完美地拼装并缝合在一起。任何贪图一时之快而盲目导入了全量业务模块的通用“公共辅助（utilities）包”，久而久之都必然会以极高概率堕落并蜕变为架空系统依赖架构、引发无限引用混乱的架构大“旁路”。在研发日常中，应当配置自动化静态检查去高频监控并追踪循环引用（dependency cycles）、公共接口暴露面（public API surface）以及底层的扇出复杂度（fan-out）。最后，随着编译生态中各种加载插件（Plugins）的兴起与更迭，我们必须为其量身定制强有力的面向系统能力的隔离边界与带版本控制的安全接口（versioned interface）；容忍或开放外部插件去任意读写同进程内的核心指针，最终往往会将编译器里的每一个局部的实现细节甚至是漏洞，全都要被迫转入对外部意外做出的终身兼容性历史承托。

增量工作要求精确依赖

Incremental compiler 只有在所有相关输入都没变化时才能复用结果。Cache key 可能包含 source hash、flags、target triple、language edition、imported interface、环境假设和 compiler build ID。Under-invalidation 会返回陈旧 wrong code；over-invalidation 虽然正确，却会变慢。应显式建模 query 与依赖，记录 query 为什么重新执行，并分别测试 public interface 与 private function body 的变更。

Observability 让架构主张变得可测量。把时间和内存归因到具体 pass，统计 IR growth，记录 cache hit/miss 原因，并输出能把慢构建连接到 query 而非匿名线程的 trace。性能测试要使用代表性 workload 和固定环境；一个 microbenchmark 的提升可能只是把成本推迟到后续 pass，或增加生成代码尺寸。

可复现性（Reproducibility）是发布的终极功能属性

可复现构建（Reproducible build）可以强力保障我们在世界任何一个角落、从完全相同的一组声明格式输入出发，都必定能够产生出于原本毫厘不差、完全等价的输出文件（artifact）。这就要求我们在生产发布时必须无情地：将编译期本身的依赖库版本全面硬编码锁死，强引高密封闭的编译工具链（hermetic tools），统一对发射出的临时调试嵌入路径进行前缀剥离与重映像，明确在编译逻辑中统一限制并清除任意具有动态特征的时间戳属性，将所有的 map 结构或文件系统遍历排序不变量在算法层面锁死，并强硬地基于当前编译文件的实际内容计算生成的编译 ID，而不是单纯取无谓的机器系统时钟（wall clock）。最终产出的二进制制品（binary）最好在最严苛的字节级（byte-for-byte）比对下保持完美一致；即使是部分数字签名或打包逻辑出于商业与安全合规规定不可避免地要引入一些无法抹除的变化，也必须提前定义并能够对其内容负载（normalized payload）进行绝对安全的白名单自动化过滤校验。

持续集成（CI）系统的 Presubmit 测试流水线必须要能在物理上全面覆盖编译器所主打支持的各大主流 Host/Target 宿主与后端平台矩阵交叉，但绝对不能盲目把所有维度相乘导致构建时间膨胀。测试工程应当：通过合理 Presubmit 去高频触发极速冒烟测试，通过高合规的分片技术（sharding）并确定性地对测试套件（suite）进行多核分发，最后将较慢的安全、越界及并发现场检测器测试（sanitizer）、模糊测试（fuzz tests）、编译自举测试（bootstrap runs）以及交叉平台构建任务分流到每日一测的定时任务中。Harness 仅能够在当前的 cache key 百分之百匹配的前提下才被允许去远程复用已生成的 artifacts，并且必须在解压并加载该二进制文件时严防其元数据可能带入的安全风险。任何极易在流水线中引发偶发性通过失败、难以被稳定复现测试的不稳定测试（flaky test），通通都是在技术上具有明确负责人和期限的缺陷（flaky test）；retry 可以收集证据，但不能把反复失败变成成功。

发布工程（Release engineering）的实际产物不应当仅仅幕后由一条合格绿灯标志。对于交付的生产制品，通常应当配备：完整的全生命周期可信链文件（provenance）、标准校验和哈希签名文件（checksum）、不匹配调试符号（debug symbols）、源码映射文件（source mappings）、产品软件授权协议（licenses）以及结构完备的底层依赖清单 SBOM 证书；一切对于 artifacts 的下发都必须经过官方数字签名的身份安全校验；并配备自动化安装、卸载以及向历史旧版本的安全一键级联回退（rollback）机制；完整且长久存档复现当前 toolchain 中去所不可缺少的精确编译器二进制历史清单。金丝雀通道（Canary channel）应当能在生产上平稳地先将一小批全新的 beta release 逐步暴露给少数极其活跃和对故障高宽容度的极客社群，并时刻重点监控后台有无一发出了全新一轮的机器码分析崩溃、意外的误编译（miscompilation codes）报告、编译时间膨胀、或者用户侧在体验上的任何退化报错。即使由于诊断分析而在终端引入了遥测信息（telemetry），也必须在全生命周期内誓死维护用户的隐私边界，并且保证所有的遥测报错指针能够以最完美、最严整的数字映射对应回当次生成的 build ID 上。

最后还要为删除而设计。Feature flag、实验 IR form、target hook 与 compatibility shim 都需要负责人和退出条件。在约束代码附近记录 architectural decision 与 migration path；证据表明路径无人使用后，就应定期删除。维护不是冻结编译器结构，而是建立边界、证据与发布纪律，使实现能持续演化，同时仍可判断它是否正确。