理解ECMAScript规范（Part 4）

March 10, 2024

ecma262

原文：https://v8.dev/blog/understanding-ecmascript-part-4

网络上的其它文章

来自 Mozilla 的 Jason Orendorff 发表了一篇深入分析 JS 怪异语法的精彩文章。虽然实现细节有所不同，但每个 JS 引擎都会在这些怪异上遇到相同的问题。

覆盖语法

在本章节中，我们将更深入地了解 覆盖语法。它们是一种指定语法结构的语法的方法，乍一看这些语法结构似乎有歧义。

同样，为了简洁，这里将跳过 [In, Yield, Await] 中的下标，因为它们对于本文不重要。
有关其含义和用法的解释，请参阅第 3 部分。

有限前瞻

通常，解析器根据有限前瞻（固定数量的后续标记）来决定使用哪个生成。

在某些情况下，下一个标记会明确确定要使用的生成。例如：

UpdateExpression :
  LeftHandSideExpression
  LeftHandSideExpression ++
  LeftHandSideExpression --
  ++ UnaryExpression
  -- UnaryExpression

如果我们正在解析一个 UpdateExpression 和下一个标记是 ++ 或 --，我们马上就知道要使用的生成。
如果下一个标记不是，也不算坏：我们可以从我们所在的位置开始解析一个 LeftHandSideExpression，并在解析完它之后弄清楚接下来该怎么做。

如果 LeftHandSideExpression 后的标记是 ++，那么要使用的生成就是 UpdateExpression: LeftHandSideExpression ++。对于 -- 的情况也是类似的。
并且，如果 LeftHandSideExpression 后的标记既不是 ++ 也不是 --，那么我们使用生成 UpdateExpression : LeftHandSideExpression。

箭头函数参数列表还是带圆括号的表达式？

区分箭头函数参数列表和带圆括号的表达式更复杂。

例如：

let x = (a,

这是否是箭头函数的开头，就像这样？

let x = (a, b) => { return a + b };

或者，它可能是带圆括号的表达式，就像这样？

let x = (a, 3);

带圆括号的任何东西都可以任意长 - 我们无法根据有限数量的标记知道它的内容。

让我们想象一下，我们有以下简单的生成：

AssignmentExpression :
  ...
  ArrowFunction
  ParenthesizedExpression

ArrowFunction :
  ArrowParameterList => ConciseBody

现在我们无法使用有限前瞻来选择要使用的生成。如果我们必须解析一个 AssignmentExpression 且下一个标记是 (，我们如何决定接下来解析什么？
我们可以解析一个 ArrowParameterList 也可以解析一个 ParenthesizedExpression，但我们的猜测可能会出错。

非常宽松的新符号：`CPEAAPL`

规范通过引入符号 CoverParenthesizedExpressionAndArrowParameterList（覆盖带括号的表达式和箭头参数列表，简称 CPEAAPL）解决了这个问题。CPEAAPL 实际上是一个 ParenthesizedExpression 或一个 ArrowParameterList，但我们现在还不知道哪一个。

CPEAAPL 的生成非常宽松，允许所有可以在 ParenthesizedExpression 和 ArrowParameterList 中出现的结构：

CPEAAPL :
  ( Expression )
  ( Expression , )
  ( )
  ( ... BindingIdentifier )
  ( ... BindingPattern )
  ( Expression , ... BindingIdentifier )
  ( Expression , ... BindingPattern )

例如，以下表达式是有效的 CPEAAPL：

// 有效的 ParenthesizedExpression 和 ArrowParameterList：
(a, b)
(a, b = 1)

// 有效的 ParenthesizedExpression：
(1, 2, 3)
(function foo() { })

// 有效的 ArrowParameterList：
()
(a, b,)
(a, ...b)
(a = 1, ...b)

// 既无效也不有效，但仍然是 CPEAAPL：
(1, ...b)
(1, )

尾随逗号和 ... 只能出现在 ArrowParameterList 中。某些结构，如 b = 1 可以在两者中出现，但它们的含义不同：
在 ParenthesizedExpression 内是一个赋值，在 ArrowParameterList 内是一个有默认值的参数。
不是有效参数名称（或参数解构模式）的数字和其他 PrimaryExpressions 只能出现在 ParenthesizedExpression 中。
但它们都可以在 CPEAAPL 中出现。

在生成中使用 `CPEAAPL`

现在，我们可以在 AssignmentExpression 生成中使用非常宽松的 CPEAAPL。
（注意：ConditionalExpression 通过一个这里未显示的长生成链导致 PrimaryExpression。）

AssignmentExpression :
  ConditionalExpression
  ArrowFunction
  ...

ArrowFunction :
  ArrowParameters => ConciseBody

ArrowParameters :
  BindingIdentifier
  CPEAAPL

PrimaryExpression :
  ...
  CPEAAPL

试想我们再次遇到这种情况，我们需要解析一个 AssignmentExpression 且下一个标记是 (。
现在，我们可以解析一个 CPEAAPL，并在稍后弄清楚要使用哪个生成。
无论我们要解析一个 ArrowFunction 还是一个 ConditionalExpression 都没关系，无论如何，下一个要解析的符号都在 CPEAAPL 中！

在解析完 CPEAAPL 之后，我们可以决定针对原始 AssignmentExpression（包含 CPEAAPL 的那个）使用哪个生成。该决定是根据 CPEAAPL 后的标记做出的。

如果标记是 =>，我们使用生成：

AssignmentExpression :
  ArrowFunction

如果标记是其他东西，我们使用生成：

AssignmentExpression :
  ConditionalExpression

例如：

let x = (a, b) => { return a + b; };
//      ^^^^^^
//     CPEAAPL
//             ^^
//             CPEAAPL 后的标记

let x = (a, 3);
//      ^^^^^^
//     CPEAAPL
//            ^
//            CPEAAPL 后的标记

此时，我们可以将 CPEAAPL 保留原样，并继续解析程序的其余部分。
例如，如果 CPEAAPL 位于 ArrowFunction 中，我们暂时不必查看它是否是有效的箭头函数参数列表 - 稍后可以完成此操作。
（现实中的解析器可能会选择立即执行有效性检查，但从规范的角度来看，我们无需这样做。）

限制 CPEAAPL

正如我们之前看到的，CPEAAPL 的语法生成非常宽松，并允许无效的结构（例如 (1, ...a)）。
在根据语法解析完程序之后，我们需要禁止相应的非法结构。

规范通过添加以下限制来实现此目的：

静态语义：早期错误

PrimaryExpression : CPEAAPL

如果 CPEAAPL 没有覆盖 ParenthesizedExpression，则这是语法错误。

补充语法

在处理生成

PrimaryExpression : CPEAAPL

的实例时，使用以下语法来精炼（refine）CPEAAPL 的解释：

ParenthesizedExpression : ( Expression )

这意味着：如果 CPEAAPL 出现在语法树中 PrimaryExpression 的位置，它实际上是一个 ParenthesizedExpression，并且这是其唯一有效生成。

Expression 永远不能为空，所以 ( ) 不是有效的 ParenthesizedExpression。
像 (1, 2, 3) 这样的逗号分隔列表是由逗号操作符创建的：

Expression :
  AssignmentExpression
  Expression , AssignmentExpression

类似地，如果 CPEAAPL 出现 ArrowParameters 的位置，则适用以下限制：

静态语义：早期错误

ArrowParameters : CPEAAPL

如果 CPEAAPL 没有覆盖 ArrowFormalParameters，则这是语法错误。

补充语法

当识别生成

ArrowParameters : CPEAAPL

时，使用以下语法来精炼（refine）CPEAAPL 的解释：

ArrowFormalParameters :
( UniqueFormalParameters )

其他覆盖语法

除了 CPEAAPL 之外，规范还将覆盖语法用于其他看起来模棱两可的结构。

ObjectLiteral 被用作覆盖语法，用于出现在箭头函数参数列表中的 ObjectAssignmentPattern。
这意味着 ObjectLiteral 允许不能出现在实际对象文字中的结构。

ObjectLiteral :
  ...
  { PropertyDefinitionList }

PropertyDefinition :
  ...
  CoverInitializedName

CoverInitializedName :
  IdentifierReference Initializer

Initializer :
  = AssignmentExpression

例如：

let o = { a = 1 }; // 语法错误

// 具有具有默认值的解构参数的箭头函数：
let f = ({ a = 1 }) => { return a; };
f({}); // 返回 1
f({a : 6}); // 返回 6

异步箭头函数在有限前瞻下看起来也很模棱两可：

let x = async(a,

这是调用名为 async 的函数还是异步箭头函数？

let x1 = async(a, b);
let x2 = async();
function async() { }

let x3 = async(a, b) => {};
let x4 = async();

为此，语法定义了一个覆盖语法符号 CoverCallExpressionAndAsyncArrowHead，其工作方式与 CPEAAPL 类似。

总结

在本集中，我们研究了规范如何定义覆盖语法，以及在无法根据有限前瞻识别当前语法结构的情况下如何使用它们。

具体来说，我们研究了区分箭头函数参数列表与括号表达式以及规范如何通过在解析阶段使用覆盖语法来宽松地解析模棱两可的结构，并在稍后使用静态语义规则对其进行限制。

←Back to home

This work is licensed under CC BY-NC-SA 4.0