Scala.js Wasm 后端中 try..finally 与不可空引用类型的兼容性问题

在 Scala.js 的 WebAssembly (Wasm) 后端实现中，当开发者使用 try..finally 语句块并结合不可空引用类型时，编译器会生成无效的 Wasm 代码。这个问题源于 Wasm 严格的类型验证机制与 Scala 语言特性的交互方式。

问题本质

当 Scala 代码中包含 try..finally 结构，并且在 try 块中返回一个不可空引用类型时，编译器生成的 Wasm 字节码无法通过验证。具体表现为 Wasm 虚拟机抛出的 "uninitialized non-defaultable local" 错误。

这个问题出现的原因是 Wasm 的验证器无法确定在所有代码路径中局部变量是否都被正确初始化。在 try..finally 结构中，如果 try 块抛出异常，理论上不应该访问 finally 块之后的代码，但 Wasm 的静态验证器无法做出这种假设。

技术细节分析

以示例代码为例：

def test(): Unit = {
  var a = 1
  val some = try {
    Some(a)
  } finally {
    a = 2
  }
  assert(some.value == 1)
}

编译器生成的 Wasm 代码中，关键问题出现在对局部变量 $1 的处理上。这个变量被声明为不可空引用类型 (ref $c.Some)，但在异常情况下它不会被初始化，而 Wasm 验证器要求所有非默认类型的局部变量在所有可能的执行路径上都必须被初始化。

解决方案

正确的处理方式是：

1. 对于 try..finally 结构中可能未被初始化的局部变量，始终使用可空类型（如 (ref null $c.Some)）
2. 在读取这些变量时，通过类型转换去除可空性
3. 确保在正常执行路径上，变量确实会被正确初始化

这种处理方式既满足了 Wasm 的验证要求，又保持了 Scala 语言的语义完整性。

对开发者的影响

虽然这个问题主要影响编译器内部的代码生成，但开发者需要注意：

1. 在 Wasm 目标上使用 try..finally 时，避免依赖复杂的类型推断
2. 如果遇到类似的验证错误，考虑简化异常处理逻辑
3. 确保在 finally 块中不假设 try 块一定成功执行

总结

Scala.js 团队已经修复了这个问题，通过确保在 try..finally 结构中正确处理局部变量的可空性。这个案例展示了将高级语言特性编译到 Wasm 时可能遇到的类型系统挑战，以及如何在保持语言语义的同时满足目标平台的验证要求。