Pegjs: 启用/禁用缓存时返回的不同错误

创建于 2016-08-28  ·  20评论  ·  资料来源: pegjs/pegjs

语法:

Statement
  = "{" __ !Statement Statement __ "}"
__
  = [ \t\r\n]*

输入:

{x}

禁用结果缓存后,上述内容会产生此错误:

应为“{”或 [ \t\r\n] 但找到了“x”。

启用结果缓存后,错误更改为:

应为 [ \t\r\n] 但找到了 "x"。

两种情况下的错误应该相同。

原始报告

最有用的评论

您可以在此处查看修复程序。

所有20条评论

我依靠极具表现力的SyntaxError s pegjs throws 为用户构建语法完成。

但是,这个问题阻止我对更复杂的语法这样做:

  • 启用缓存后,它会抑制可能的匹配
  • 没有缓存,解析速度会减慢,使其无法使用

错误适用的另一种语法:

Start
    = Char+ End

End
    = "e"

Char
    = (!End [a-z])+

输入:

a

禁用结果缓存后,上述内容会产生此错误:

应为“e”、[az] 或不是“e”但已找到输入的结尾。

启用结果缓存后,错误更改为:

应为 [az],但发现输入结束。

缓存禁用错误是正确的,因为ae与语法匹配。

失败的测试用例添加 #555

这个问题的原因似乎是:

  • 在规则的初始评估期间,调用peg$expect来记录预期的标记。 在某些情况下( peg$silentFails > 0 )令牌会被忽略。

  • 缓存评估期间,正在恢复缓存的结果。 此时,解析器不仅必须恢复新的解析状态,还必须重放对peg$expect相关调用。 否则它会错过预期的令牌。 这体现在上面看到的不完整的错误消息中。

在基于[email protected]的本地原型中,我能够通过记录和重放对peg$expect调用来解决这个问题。 然而,随着https://github.com/pegjs/pegjs/commit/669f782a5f3928a2958147992eb07df5b0ecf54a 中引入的变化,这些东西变得更加复杂。

我可以尝试修复pegjs@dev 。 只是想知道我是否朝着正确的方向前进。

任何评论@Mingun ,@futagoza?

你能告诉我你基于[email protected]本地原型吗?

您可以在此处查看修复程序。

对于嵌套的静音元素,它还不能正常工作:

语法:

Start
  = Char+ End
End "end"
  = "e"
Char
  = !End [a-z]'

输入:

a

预期消息:

预期结束,或 [az] 但找到输入结束。

实际消息:

预期结束,“e”或 [az] 但找到输入结束。

参见失败的测试用例

@nikku现在应该解决这个问题(感谢你 🙇 ),所有 3 个测试用例都通过了(包括第 3 个用于嵌套静默元素的测试用例)。

最新的pegjs@dev版本中的修复程序只是推送到 NPM, [email protected] (https://github.com/pegjs/pegjs#latest)。

谢谢。

我今天测试了您的更改。

从我看到的https://github.com/pegjs/pegjs/commit/f5b323b40124e9ebe1336b509af0716d5a31ce55#diff -cd2c6b13fdcedf68a390c8bb6ea65cafR148 有效地引入了一个破坏性的变化,因为它引入了一个破坏性的变化peg$silentFails === 0 parse peg$silentFails === 0 parse --no-cache .

😨 哎呀,这是一个愚蠢的错误。 很快就会解决这个问题,谢谢你的提醒

试图创建一个测试用例但失败了: cry:。 不过,我看到该行对我的一个更复杂的语法产生了影响。

恢复了https://github.com/pegjs/pegjs/commit/d06a5b52efcf0fa4b9e5bf21f97607786c1c7db5 中的守卫并将更改推送到pegjs@dev ,告诉我这是否解决了问题

@nikku是否已修复,或者您仍然遇到此问题? 只是想知道我是否应该重新打开这个问题。

它是固定的。

@nikku - 这不是固定的。 什么都没有被释放。 npm仍然有0.10.0 ,这被合并到一个功能0.11.0分支,ryuu 说这个分支实际上永远不会发布

正是出于这个原因,我很久以前就不再希望使用 pegjs,而是在别处寻找。

没有发布 = 没有人可以实际使用它。 Pegjs 在发布方面历来都很糟糕。

我希望通过以下方式改变挂钩发布周期:

  1. 要求原主人允许我从0.10.0重新剪下0.12.0 0.10.0
  2. 从现已死亡的0.11.0分支中挑选并持续快速发布功能,
  3. 删除不常见的工具和配置,以支持标准的开发设置,以及
  4. 将库置于社区易于添加功能的地方

如果发生这样的事情,在任何一组手中,然后真正开始发布,你会再给它一次机会吗?

祝你好运实现这一目标。

谢谢😁

走着瞧。

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

richb-hanover picture richb-hanover  ·  7评论

gatsbyz picture gatsbyz  ·  3评论

mattkanwisher picture mattkanwisher  ·  5评论

emmenko picture emmenko  ·  15评论

futagoza picture futagoza  ·  13评论