Dart SDK Wasm编译器中参数传递错误的修复分析

问题背景

在Dart SDK的Wasm编译器(dart2wasm)中，开发者在运行convert包的测试用例时发现了一个奇怪的运行时错误。当使用Chrome浏览器执行测试时，控制台输出了WebAssembly编译错误，提示类型不匹配问题。

错误现象

具体错误信息显示，在编译函数"JsonCodec.decode (unchecked entry)"时失败，错误原因是"local.set[0] expected type (ref null 83), found if of type (ref 11)"。这表明在Wasm模块编译阶段出现了类型系统不匹配的问题。

问题定位

经过技术专家分析，这个问题出现在Dart 3.7.0到main分支之间的某个变更引入的。通过深入调试发现，问题根源在于checked entry和unchecked entry之间的调用关系上。

在Wasm调试环境下，可以观察到以下调用栈：

1. 从unchecked entry调用checked entry
2. checked entry中尝试将整型参数强制转换为布尔型
3. 导致非法类型转换异常

技术分析

问题的核心在于参数传递机制的错误。具体表现为：

1. 在checked entry函数中，编译器错误地将一个整型参数(BoxedInt)当作布尔型参数(BoxedBool)来处理
2. 实际上，布尔参数应该以未装箱的i32形式传递
3. 这种参数传递错误源于编译器在设置参数时错误地假设了直接调用方式，而实际上函数是通过调度表间接调用的

修复方案

修复的关键在于正确处理间接调用时的参数传递机制：

1. 对于通过调度表间接调用的函数，需要确保参数传递方式与直接调用一致
2. 布尔参数应该以未装箱的i32形式传递，而不是装箱形式
3. 在checked entry中正确识别和处理各种参数类型

影响范围

这个问题主要影响：

1. 使用dart2wasm编译的Dart程序
2. 涉及类型检查和转换的代码路径
3. 特别是那些通过调度表间接调用的函数

开发者建议

对于Dart开发者来说，遇到类似Wasm编译错误时，可以：

1. 首先尝试简化测试用例，缩小问题范围
2. 关注类型转换相关的代码路径
3. 检查函数调用方式（直接调用还是间接调用）
4. 关注Dart SDK的更新，及时获取修复

总结

这个问题的修复体现了Dart Wasm编译器在类型系统和调用约定处理上的不断完善。随着Dart对WebAssembly支持的持续改进，开发者可以期待更稳定和高效的Wasm编译体验。该修复已经合并到Dart SDK的主分支，并将随下一个稳定版本发布。