Rustfmt 处理非NFC规范化标识符时发生内部编译器错误的分析与解决

问题背景

在Rust编程语言中，标识符(identifier)支持使用Unicode字符。Unicode标准中，某些字符可以通过多种方式表示，例如字母"ó"可以表示为单个码点U+00F3（预组合形式），也可以表示为ASCII字母"o"后跟组合重音符号U+0301（分解形式）。这两种表示形式在Unicode标准中被称为"规范化形式"。

Rust编译器在处理标识符时会自动执行NFC(规范化形式C)规范化，确保不同表示形式的相同字符被统一处理。然而，当Rust格式化工具rustfmt遇到非NFC规范化的标识符时，在某些情况下会出现内部编译器错误(ICE)。

问题重现

考虑以下Rust代码示例：

trait Foó: Bar {}

在这个例子中，Foó中的ó由两个码点组成：ASCII字母o(U+006F)后跟组合重音符号U+0301。这种表示形式不是NFC规范化的，其NFC规范化形式应为单个码点U+00F3(ó)。

当尝试使用rustfmt格式化上述代码时，工具会崩溃并报告内部编译器错误，错误信息表明在处理span时出现问题。

技术分析

问题的根源在于rustfmt和编译器在处理标识符时的交互方式：

1. 编译器在解析代码时会对所有标识符执行NFC规范化，因此Foó(两个码点)在编译器内部会被规范化为Fó(单个码点)。

2. 然而，rustfmt在格式化代码时需要操作原始源代码文本，此时它尝试在包含非规范化形式的原始文本中查找已经规范化的标识符。

3. 具体来说，在格式化trait定义时，rustfmt会调用span_after方法来定位标识符后的位置。该方法接收两个参数：整个项的span和标识符字符串。由于传入的是规范化后的标识符字符串，而源代码中包含的是非规范化的形式，导致查找失败并触发panic。

解决方案

解决这个问题的关键在于确保rustfmt在搜索源代码中的标识符时使用原始的非规范化形式，而不是编译器内部规范化后的形式。具体实现方式为：

1. 不再直接使用item.ident.as_str()获取规范化后的标识符字符串
2. 改为通过标识符的span直接从源代码片段中提取原始标识符文本
3. 使用这个原始文本来进行后续的span定位操作

这种修改确保了rustfmt始终基于源代码中的实际文本内容进行操作，避免了规范化形式不匹配的问题。

影响与意义

这个修复不仅解决了特定情况下rustfmt的崩溃问题，更重要的是：

1. 增强了rustfmt处理Unicode标识符的健壮性
2. 保持了与编译器行为的一致性
3. 为处理各种Unicode规范化形式的标识符提供了可靠的基础

对于Rust开发者来说，这意味着可以更自由地使用各种Unicode字符作为标识符，而不必担心格式化工具的处理问题。这也体现了Rust生态对国际化支持的持续改进。

最佳实践建议

虽然这个问题已经得到修复，但为了代码的可维护性和可读性，建议开发者：

1. 尽量使用NFC规范化形式的Unicode字符作为标识符
2. 在团队协作项目中，统一标识符的编码规范
3. 定期使用rustfmt格式化代码，以及时发现潜在问题

通过这些实践，可以最大程度地避免因字符编码问题导致的工具链兼容性问题。