Gleam 用 JavaScript 和 Erlang 后端互相验错，模糊测试已找到九个问题
开发者 Daniel Wirtz 为 Gleam 编译器构建结构感知模糊测试工具：先随机生成能够通过类型检查的程序，再分别编译到 Erlang 和 JavaScript，比较两个后端的运行结果。目前项目已报告九个问题，其中一个进一步上报到了 Erlang/OTP。
林岚
开发者 Daniel Wirtz 为 Gleam 编译器构建结构感知模糊测试工具：先随机生成能够通过类型检查的程序，再分别编译到 Erlang 和 JavaScript，比较两个后端的运行结果。目前项目已报告九个问题，其中一个进一步上报到了 Erlang/OTP。
一句话结论：这套方法聪明之处不在“随机生成很多乱码代码”，而在利用 Gleam 的双后端作为彼此的裁判，让没有标准答案的测试也能发现代码生成差异。
普通随机字节很容易让解析器报错，却很难触达编译器深处。项目第一阶段直接通过 Gleam 的 Rust 编译器 API 调用 libFuzzer，确实找到了 Nightly 中常量表达式管道操作导致的解析崩溃。但要测试类型推导和代码生成，输入必须像真正的 Gleam 程序。
作者因此实现了一个简化 AST “smith”。当生成器需要一个 Int 表达式时，它可以选择整数、变量、返回整数的匿名函数或更复杂组合，并始终遵守当前作用域和类型。输出看起来毫无业务意义，却能把模式匹配、闭包、阴影变量、位数组和不同表达式拼出开发者很少手写的组合。
接下来是测试预言机问题：程序成功运行后，谁知道正确答案？Gleam 同时支持 Erlang 和 JavaScript，作者让同一个随机程序在两个目标运行，再解析 echo 输出进行比较。如果 Erlang 返回 true、JavaScript 返回 false，至少有一边出了问题。
比较前还要消除运行时本来就不同的表示。例如 JavaScript 会把 1.0 显示成 1，Erlang 可能把某些位数组显示成字符串，记录结构的打印格式也不同。作者为此把两边输出解析成统一的 Rust 枚举。否则，模糊测试会被大量假阳性淹没。
目前发现包括：不可达分支导致 Erlang 代码生成崩溃、UTF‑8 位数组匹配在 JavaScript 走错分支、空字符串匹配生成非法 JavaScript、局部变量阴影导致调用错误、let 阴影时 JavaScript 后端引用错误变量，以及一个连续输出触发的 Erlang/OTP 问题。数字本身不算大，但这些都来自能编译、能运行、表面合法的程序，比单纯 parser crash 更接近真实错误。
方法也有边界。两个后端可能同时产生相同错误；不同运行时语义可能造成假差异；已知缺陷会让生成器反复撞上同一种程序形状。作者现在按百个种子一批人工复核，并用错误签名跳过已知问题。下一步可加入输入缩减、变形测试、类型推导专项生成和 CI 持续运行。
关键事实
- 测试结构：解析器随机输入与类型安全程序生成分成两个阶段。
- 判断方式：同一 Gleam 程序分别运行在 Erlang、JavaScript 后端并比较规范化输出。
- 当前结果：九个问题，其中一个上报 Erlang/OTP。
- 实现基础：编译器以 Rust 编写，测试直接使用公开编译器 API 与现有模糊测试工具。
OC 判断
双后端不是 Gleam 的维护负担，也可以变成测试资产。只要先处理运行时固有差异，它们就提供了一种便宜的差分测试预言机。比起让 LLM 随机写代码，这种受类型系统约束的生成器更可控、更容易复现。
为什么重要
- 对语言维护者：随机测试可以进入 CI，长期积累难以手写的边界样本。
- 对编译器开发者：多后端实现天然适合差分测试，但要认真控制假阳性。
- 对普通开发者：编译成功不代表两个目标行为一致，跨后端项目仍需实际运行测试。
评论
围绕这篇文章补充信息、提出问题或分享观察。