JsLex 错误地解释了哪些 Javascript 构造？

Question

JsLex 是我用 Python 编写的 Javascript 词法分析器。它可以很好地完成一天（左右）的工作，但我确信在某些情况下它会出错。特别是，它对分号插入一无所知，并且可能有一些对词法分析很重要的方法。我只是不知道它们是什么。

哪些 Javascript 代码 JsLex lex 不正确？我对有效的 Javascript 源特别感兴趣，其中 JsLex 错误地识别了正则表达式文字。

需要明确的是，“词法分析”是指识别源文件中的标记。 JsLex 不会尝试解析 Javascript，更不用说执行它了。我编写了 JsLex 来进行完整的词法分析，不过说实话，如果它能够成功找到所有正则表达式文字，我会很高兴。

Answer 1

有趣的是，我在用 JS 编写的词法分析器/求值器的代码上尝试了您的词法分析器；）您是对的，它并不总是能很好地处理正则表达式。这里有一些例子：

rexl.re = {
  NAME: /^(?!\d)(?:\w)+|^"(?:[^"]|"")+"/,
  UNQUOTED_LITERAL: /^@(?:(?!\d)(?:\w|\:)+|^"(?:[^"]|"")+")\[[^\]]+\]/,
  QUOTED_LITERAL: /^'(?:[^']|'')*'/,
  NUMERIC_LITERAL: /^[0-9]+(?:\.[0-9]*(?:[eE][-+][0-9]+)?)?/,
  SYMBOL: /^(?:==|=|<>|<=|<|>=|>|!~~|!~|~~|~|!==|!=|!~=|!~|!|&|\||\.|\:|,|\(|\)|\[|\]|\{|\}|\?|\:|;|@|\^|\/\+|\/|\*|\+|-)/
};

这个大部分都很好 - 只有 UNQUITED_LITERAL 未被识别，否则一切都很好。但现在让我们对它做一个小的补充：

rexl.re = {
  NAME: /^(?!\d)(?:\w)+|^"(?:[^"]|"")+"/,
  UNQUOTED_LITERAL: /^@(?:(?!\d)(?:\w|\:)+|^"(?:[^"]|"")+")\[[^\]]+\]/,
  QUOTED_LITERAL: /^'(?:[^']|'')*'/,
  NUMERIC_LITERAL: /^[0-9]+(?:\.[0-9]*(?:[eE][-+][0-9]+)?)?/,
  SYMBOL: /^(?:==|=|<>|<=|<|>=|>|!~~|!~|~~|~|!==|!=|!~=|!~|!|&|\||\.|\:|,|\(|\)|\[|\]|\{|\}|\?|\:|;|@|\^|\/\+|\/|\*|\+|-)/
};
str = '"';

现在都是在 NAME's 正则表达式混乱之后。它可以制作 1 根大绳子。我认为后一个问题是String token太贪婪了。对于 regex 令牌来说，前一个可能过于智能。

编辑：我想我已经修复了regex令牌的正则表达式。在代码中，将第 146-153 行（整个“后续字符”部分）替换为以下表达式：

([^/]|(?<!\\)(?<=\\)/)*

这个想法是允许除 / 之外的所有内容，还允许 \/，但不允许 \\/。

编辑：另一个有趣的案例，在修复后通过，但添加为内置测试案例可能会很有趣：

    case 'UNQUOTED_LITERAL': 
    case 'QUOTED_LITERAL': {
        this._js =  "e.str(\"" + this.value.replace(/\\/g, "\\\\").replace(/"/g, "\\\"") + "\")";
        break;
    }

编辑：又一个案例。它似乎对关键词也太贪婪了。查看案例：

var clazz = function() {
    if (clazz.__) return delete(clazz.__);
    this.constructor = clazz;
    if(constructor)
        constructor.apply(this, arguments);
};

它将其词法为：(keyword, const), (id, ructor)。对于标识符 inherits 也会发生同样的情况：in 和 herits。

Answer 2

示例：下面第一次出现的 / 2 /i（对 a 的赋值）应标记为 Div、NumericLiteral、Div、标识符，因为它位于 InputElementDiv 上下文中。第二次出现（对 b 的赋值）应标记为 RegularExpressionLiteral，因为它位于 InputElementRegExp 上下文中。

i = 1;
var a = 1 / 2 /i;
console.info(a); // ⇒ 0.5
console.info(typeof a); // number

var b = 1 + / 2 /i;
console.info(b); // ⇒ 1/2/i
console.info(typeof b); // ⇒ string

来源：

词法语法有两个目标符号。 InputElementDiv 符号用在允许除法 (/) 或除法赋值 (/=) 运算符的语法上下文中。 InputElementRegExp 符号用于其他语法上下文。

请注意，句法语法中存在上下文，其中句法语法允许除法和正则表达式文字；但是，由于在这种情况下词法语法使用 InputElementDiv 目标符号，因此在这种情况下，开头斜杠不会被识别为开始正则表达式文字。作为一种解决方法，可以将正则表达式文字括在括号中。
— 标准 ECMA-262 第三版 - 1999 年 12 月，第 14 页11

Answer 3

处理这个棘手问题的简单解决方案非常酷，但我注意到它并不能完全处理 ES5 的 something.property 语法的更改，该更改允许在 后面使用保留字.。即，a.if = 'foo'; (function () {a.if /= 3;});，是 一些最近的实现。

除非我弄错了，否则 . 无论如何对于属性都只有一种用途，因此解决方案可能是在 .< /code> 只接受 identifierName 标记（这是 identifier 使用的，但它不拒绝保留字）可能会成功。 （显然 div 状态照常遵循。）

Answer 4

我一直在思考自己为 JavaScript 编写词法分析器的问题，我刚刚在寻找好的技术时遇到了你的实现。我发现了一个你的不起作用的情况，如果你仍然感兴趣，我想我会分享：

var g = 3, x = { valueOf: function() { return 6;} } /2/g;

斜杠都应该被解析为除法运算符，导致 x 被分配数值 1。你的词法分析器认为它是一个正则表达式。如果不维护一组分组上下文来区分块的结尾（期望正则表达式）和函数语句的结尾，则无法正确处理这种情况的所有变体。 strong>（期望正则表达式）、函数表达式的结尾（期望除法）以及对象文字的结尾（期望除法）。

Answer 5

它对于这段代码是否可以正常工作（这不应该有分号；正确地词法分析时会产生错误）？

function square(num) {
    var result;
    var f = function (x) {
        return x * x;
    }
    (result = f(num));
    return result;
}

如果是这样，它对于依赖分号插入的代码是否可以正常工作？

function square(num) {
    var f = function (x) {
        return x * x;
    }
    return f(num);
}