WATaBoy：把 Game Boy 指令 JIT 到 Wasm，跑得比原生解释器还快

这条最抓眼球的地方，在于作者没有停在“Rust 写了个 Game Boy 模拟器”这一层，而是把 SM83 指令动态重编译到 Wasm，再借浏览器引擎的 JIT 把 Wasm 继续编译成原生机器码。作者给出的结论很直接：这套 JIT-to-Wasm 路线不仅能跨平台，甚至在浏览器里也能 稳定跑赢原生解释器。如果你以前把“浏览器里的 Wasm”更多看成部署便利，这个项目会把它往“性能工具链”重新拉一遍。

更有意思的是，它瞄准的还是一个通常不太会被认为特别适合 JIT 的对象：Game Boy 模拟器。文章里提到，作者没有直接生成原生代码，而是利用 WebAssembly 作为中间层，借 JavaScriptCore / WebKit 的能力，在 iOS 这类对传统 JIT 限制严格的平台上绕出一条现实可行的路。换句话说，它展示的不是“Wasm 也能跑 emulator”这么简单，而是 把 Wasm 当作可移植 JIT 落点 来用。

从工程角度看，这篇文章的含金量还在于它没有只晒结果，而是认真展开了 Rust 内生成 Wasm 字节码、通过 embedder 编译/实例化、再接回间接调用表 的实现路径。对关心运行时代码生成、解释器优化、浏览器宿主限制的人来说，这已经不只是个玩具项目，而是一份很有参考价值的实现笔记。

原文链接：https://humphri.es/blog/WATaBoy/ 项目地址：https://github.com/EnergeticBark/WATaBoy

Kani：Rust 模型检查器从“找 bug”走向“给正确性证明兜底”

如果说很多人对 Kani 的印象还停留在“Rust 形式化验证工具”，这篇新论文把它的定位讲得更完整了。作者强调，Rust 的所有权系统能很好地挡住安全代码里的内存错误，但像 unsafe 操作是否可靠、函数是否满足功能正确性、程序是否不会 panic 这类性质，并不会因为编译通过就自动成立。Kani 要补的正是这段空白：它把 Rust 的 MIR 转进 CBMC 的位精确验证引擎里，对证明 harness 做边界模型检查。

这篇论文最值得注意的，不只是“又能验证更多东西”，而是它开始明确往 可扩展规格语言 上走。论文里提到，Kani 提供了函数契约、循环契约、量词和函数桩替换等能力，让验证从有限展开继续向更强的正确性表达推进。作者还给出一个很有传播力的数据点：在工业案例里，这些契约帮助他们把验证目标从 panic-freedom 升级到功能正确性，并发现了 6 个此前未知的 bug。

另一个信号是规模。论文直接写到，Kani 已经用于生产 CI 场景，在 Rust 标准库验证工作里，每次代码变更要检查超过 16,000 个 harness。这意味着它讨论的已经不是“实验室里能跑起来的验证器”，而是一个开始真正嵌入大型 Rust 工程流程的工具链。对 Rust 社区来说，这种工具成熟度的提升，比单纯多一篇论文更重要。

原文链接：https://arxiv.org/abs/2607.01504 项目地址：https://github.com/model-checking/kani

rust-analyzer Changelog #335：新诊断、cargo.configPath 与一串崩溃修复一起落地

今天这版 rust-analyzer #335 不算那种“单一超级功能”的发布，但对日常开发体验很实用。新特性里比较醒目的有三个：新增 union-pat-has-rest 诊断、yield-outside-of-coroutine 诊断，以及新的 cargo.configPath 设置项。前两个继续补齐语义分析和诊断覆盖，后一个则更偏向工程配置层面的可控性，对有复杂 Cargo 布局或自定义环境的人会比较有用。

性能方面，这版虽然没打出特别夸张的 headline，但也做了几项很典型的底层打磨，比如 减少 parser joint token 的分配尺寸、上提 attribute qualifier segment 计算，以及删掉没再使用的 SCIP 字段。这类改动单看不炸眼，但 rust-analyzer 的响应体验本来就是靠很多这种小手术一点点堆出来的。

修复列表则相当长，重点集中在一批真实会撞到的崩溃和 lowering / macro / completion 边角问题上。像 const resolution、associated types、macro call 内 completions、递归 enum nested pattern 之类都被点名修过。对每天离不开 rust-analyzer 的人来说，这种发布最直接的意义往往不是“多了一个新按钮”，而是 少掉一串让人分神的 IDE 小故障。

原文链接：https://rust-analyzer.github.io/thisweek/2026/07/06/changelog-335.html 发布页：https://github.com/rust-analyzer/rust-analyzer/releases/2026-07-06

Girls Just Wanna Have Fast MPMC Queues：把 bounded waiting 的多生产者多消费者队列讲透了

这篇文章切口很硬核：作者尝试自己实现一个 MPMC 队列，目标不是再讲一遍“锁免费数据结构有多难”，而是围绕 bounded waiting 去构造一套更可解释的设计。文中用双 ticket counter、数据 ring buffer 和状态 ring buffer 组合出一套队列协议，让生产者 / 消费者分别领取“号牌”，再按状态位交替获得槽位访问权。这种讲法很适合 Rust 社区，因为它把原子操作、缓存行填充、内存布局和并发语义几件事揉在了一起。

作者也很诚实地在文首修正了一个关键点：这并不是真正 wait-free 的实现。原因是线程挂起仍然可能拖住其他线程，所以更准确的说法应该是“有界等待特性很强，但不满足严格的 wait-free 定义”。这一点反而让文章更值得看——它不是拿术语包装项目，而是把设计边界和理论定义摆出来讲清楚。

对 Rust 生态来说，这类内容的价值在于，它不是只给出一个 crate，而是把背后的思考路径也摊开：为什么要用 AtomicUsize、为什么缓冲区大小强制成 2 的幂、为什么状态位和 reservation number 这样编码。即使最后不直接采用作者的实现，读完也很容易把一些并发设计直觉带回自己的系统里。

原文链接：https://nahla.dev/blog/waitfree_queue/