Haxe编译器模块阴影重定义问题分析

问题背景

在Haxe编译器的最新开发版本中，当用户将鼠标悬停在标准库中被阴影覆盖的类型(如StdTypes.hx中的Void类型)上时，编译器服务器会报出"Type name Void is redefined from module StdTypes"的错误。这个错误揭示了Haxe编译器在处理模块缓存和类型检查时的一个潜在问题。

技术分析

问题的根源在于编译器服务器对模块的处理流程存在不一致性：

1. 正常编译流程：通过TyperEntry.create方法正常处理模块，并将其放入公共上下文中
2. 显示检查流程：check_display_file函数绕过正常流程，直接从缓存中查找模块

当check_display_file在缓存中找到HXB格式的模块并尝试读取时，就会触发重定义错误。这种情况特别有趣，因为它展示了两种不同路径处理同一模块时产生的冲突。

问题本质

这个问题实际上反映了Haxe编译器在处理模块缓存时的两个层面问题：

1. 设计层面：服务器不应该恢复任何其他内容
2. 容错层面：即使恢复了其他内容，也不应该以这种方式失败

虽然这个问题看起来比较特定，但它可能暴露了更普遍的设计问题。

解决方案

通过分析，我们发现这个问题实际上比最初想象的要局限得多。它只会在通过TyperEntry.create加载的模块上重现，因为这些模块会在check_display_file执行其操作之前就已经被加载。

修复方案主要涉及修改服务器模块查找逻辑：

1. 需要创建一个新函数，既能检查公共上下文又能检查缓存
2. 这个函数在找不到模块时不应启动任何类型检查过程

测试考虑

为这个问题添加测试用例有一定难度，因为我们需要请求在check_display_file操作之前就已经加载的类型。测试需要精心设计才能重现这个特定的场景。

总结

这个问题虽然表面上是关于模块阴影重定义的错误，但深入分析后我们发现它实际上揭示了Haxe编译器在处理模块缓存和类型检查路径时的一个设计缺陷。修复方案通过统一模块查找路径，避免了不同处理流程间的冲突，从而解决了这个问题。这也提醒我们在编译器设计中保持处理路径一致性的重要性。