Aptos Core 编译器解析函数类型时的语法不一致问题分析

问题背景

在Aptos Core项目的Move语言编译器v2版本中，开发者发现了一个关于函数类型解析的有趣问题。当尝试定义一个返回函数的函数类型时，编译器对|| ||u64和|| | |u64这两种看似相似的语法表现出了不一致的行为。

问题现象

开发者发现以下两种语法结构在编译器中的表现不同：

1. 第一种写法会报错：

struct Func(|| ||u64) has copy, drop;

错误信息显示解析器在第二个||处期望遇到右括号)。

2. 第二种写法却能正常通过编译：

struct Func(|| | |u64) has copy, drop;

唯一的区别是在第二个管道符号|之间多了一个空格。

技术分析

这个问题的根源在于编译器词法分析和语法分析的配合出现了偏差。具体来说：

1. 在Move语言中，函数类型使用管道符号|来界定参数和返回值类型。例如|u64| bool表示一个接受u64参数返回bool值的函数。

2. 当遇到连续两个管道符号||时，词法分析器会生成一个Tok::PipePipe标记，而不是两个单独的Tok::Pipe标记。

3. 在类型解析过程中，is_start_of_type函数负责判断当前token是否可能是一个类型的开始。这个函数目前没有考虑Tok::PipePipe的情况，导致它无法正确识别函数返回函数这种嵌套类型。

4. 有趣的是，当在||中间加入空格变成| |时，词法分析器会生成两个单独的Tok::Pipe标记，这时类型解析就能正常工作。

解决方案方向

要解决这个问题，需要从以下几个方面入手：

1. 修改is_start_of_type函数，使其能够识别Tok::PipePipe作为函数类型的开始。

2. 确保类型解析逻辑与词法分析器的输出标记保持一致。

3. 考虑是否需要调整词法分析器对连续管道符号的处理策略。

对开发者的影响

这种语法解析的不一致性会给开发者带来困惑，特别是当他们尝试定义高阶函数类型时。开发者可能会误以为Move语言不支持函数返回函数这种特性，而实际上这只是编译器实现上的一个小缺陷。

总结

这个问题展示了编译器开发中词法分析和语法分析协同工作的重要性。即使是看似微小的空格差异，也可能导致完全不同的解析结果。对于Move语言开发者来说，了解这种边缘情况有助于在遇到类似问题时更快地找到解决方案。

该问题的修复将提高编译器对高阶函数类型支持的一致性和可靠性，使开发者能够更自由地使用函数式编程范式。