Scala.js项目中IR检查错误的分析与解决

背景介绍

在Scala.js 1.18版本中，开发团队发现了一个与中间表示(IR)检查相关的重要问题。这个问题主要影响从Scala.js 1.11版本通过反序列化技巧传递过来的代码。具体表现为在Throw节点参数处理时产生了无效的IR表示。

问题本质

问题的核心在于UnwrapFromThrowable操作的处理上。在Scala.js 1.18中，这个操作被定义为UnaryOp，要求必须接收一个非空(non-nullable)参数。然而，通过反序列化技巧从1.11版本传递过来的代码，有时会生成带有空值(实际上是字面量Null())的UnwrapFromThrowable操作。

错误信息通常会显示为：

...(UnaryOp): java.lang.Throwable! expected but null found for tree of type org.scalajs.ir.Trees$Null
There were 1 IR checking errors.

触发条件

值得注意的是，这个问题不会在简单的throw new ...语句中出现，因为这类情况已经被特殊处理。问题主要出现在以下场景：

• 当抛出的是一个变量时(如throw e)
• 当抛出的是一个复杂表达式时

实际案例

在Java标准库的实现中，开发团队发现了一个典型的触发案例。具体是在java.util.Base64.Decoder.decode(ByteBuffer)方法的实现中，包含了一个throw e语句。通过以下代码可以复现这个问题：

java.util.Base64.getDecoder().decode(java.nio.ByteBuffer.wrap(Array(65, 81, 73, 61)))

类似问题

开发团队还注意到，在jlr.Array.newInstance的处理hack中，也存在类似的Array_length相关问题。不过这些问题在实际应用中出现的概率较低，因为通常如果使用1.18.0版本进行链接，也会使用对应版本的scalajs-javalib(v1.18.0)。

解决方案

开发团队通过多个提交修复了这个问题：

1. 首先识别并定位了问题根源
2. 然后对IR检查逻辑进行了修正
3. 最后确保了向后兼容性

修复确保了从旧版本反序列化过来的代码能够正确处理Throw节点的参数，同时满足1.18版本的类型系统要求。

技术意义

这个问题的解决不仅修复了一个具体的兼容性问题，更重要的是：

1. 强化了Scala.js类型系统的严谨性
2. 提高了不同版本间IR表示的兼容性处理能力
3. 为未来可能的类似问题提供了解决参考

对于使用Scala.js进行跨版本开发的用户来说，这个修复确保了代码在不同版本间的平滑迁移和稳定运行。