Scala编译器Dotty中CheckUnused阶段导致编译崩溃的问题分析

问题背景

在Scala 3编译器Dotty的最新开发版本中，开发团队发现了一个严重的回归问题。该问题导致在CheckUnused阶段（一个用于检测未使用代码的编译器阶段）出现断言失败，进而引发编译器崩溃。这一问题影响了多个开源项目，包括tgbot-utils、virgil、mongo4cats等知名Scala库。

问题表现

当编译器在处理某些特定代码结构时，会在CheckUnused阶段抛出java.lang.AssertionError: assertion failed异常。从堆栈跟踪可以看出，问题出现在isZeroExtentSynthetic方法中，该方法试图访问一个NoSpan（无位置信息）的标识符的起始位置。

技术分析

根本原因

问题的核心在于CheckUnused阶段错误地假设所有标识符都有有效的位置信息。具体来说，isZeroExtentSynthetic方法直接访问了span.start和span.end属性，而没有先检查该位置信息是否存在（即是否为NoSpan）。

在Scala编译器中，位置信息（Span）用于表示源代码中的位置范围。某些编译器生成的合成节点可能没有位置信息（即NoSpan），而CheckUnused阶段没有正确处理这种情况。

相关代码

出问题的方法实现如下：

def isZeroExtentSynthetic: Boolean = 
  pos.span.isSynthetic && pos.span.start == pos.span.end

正确的实现应该首先检查位置信息是否存在：

def isZeroExtentSynthetic: Boolean = 
  pos.span.exists && pos.span.isSynthetic && pos.span.start == pos.span.end

或者更简洁地使用现有的isZeroExtent方法：

def isZeroExtentSynthetic: Boolean = 
  pos.span.isSynthetic && pos.span.isZeroExtent

影响范围

这个问题特别容易在以下场景触发：

1. 使用宏或编译器插件生成的代码
2. 使用类型类派生（如Magnolia）的代码
3. 包含模式匹配和@unchecked注解的代码

解决方案

修复方案相对直接：在访问位置信息前确保其存在。具体来说：

1. 修改isZeroExtentSynthetic方法，正确处理NoSpan情况
2. 全面审查CheckUnused阶段中所有对位置信息的访问
3. 确保所有对isSynthetic的检查都伴随着存在性检查

经验教训

这个问题的出现提醒我们：

1. 防御性编程：编译器阶段应该对输入数据保持最小假设，特别是对于编译器生成的中间表示。
2. 位置信息处理：在Scala编译器中，位置信息是可选且可能缺失的，所有相关代码都应该考虑这一点。
3. 测试覆盖：需要增加对合成节点和无位置信息的测试用例，特别是对于静态分析相关的编译器阶段。

结论

这个看似简单的断言失败实际上揭示了Scala编译器在处理位置信息时的一个系统性弱点。通过这次修复，不仅解决了当前的崩溃问题，还提高了编译器在处理合成节点和无位置信息时的健壮性。对于Scala开发者来说，这个问题的解决意味着可以继续安全地使用类型类派生等高级特性，而不必担心编译器崩溃的风险。