Antlr3 解析不完整语句时的下一个可用令牌

Question

我试图为 SQL 的命令行客户端实现简单的自动完成。我正在使用 antlr 在应用程序的其余部分生成解析器，我想重用语法来使用自动完成功能。我的想法是： - 当用户要求完成时解析不完整的语句（例如select a from） - 从解析器中获取他提出NoViableAltException时预期的令牌列表

然后我想从这个令牌列表中做： if (isreserved_word) { 建议完成} else { 通知用户需要一个标识符}

这在原则上看起来是一个明智的想法（至少对我来说），我发现了这一点： http://www.antlr.org/wiki/pages/viewpage.action?pageId=11567208 这让我确信这是可能的

但是，经过一些测试后，我意识到state.following[state._fsp] 中的令牌并不多 例如，对于 create 的条目，它只包含 ';' 当我这部分的语法看起来像这样时：

root : statement? (SEMICOLON!)? EOF!;
statement : create | ...;
create : CREATE | ( TABLE table_create | USER user_create | ....);

于是一头雾水，看了看生成的代码：

    try {
        int alt6=16;
        alt6 = dfa6.predict(input);
        switch (alt6) {
            case 1 :
                {
                root_0 = (CommonTree)adaptor.nil();

                pushFollow(FOLLOW_create_in_statement1088);
                create8=create();

                state._fsp--;

                adaptor.addChild(root_0, create8.getTree());

                }
                break;
            case 2 :
            ...

所以这对我来说是有意义的：解析器尝试读取下一个标记，然后从这个标记中找到（切换大小写）下一个规则。 在我的情况下，预测只是失败，因为没有下一个令牌。 所以从那里我知道我需要破解一点 antlr 并查看模板和 Java.stg 我找到了这些代码：

/** A (...) subrule with multiple alternatives */
block(alts,decls,decision,enclosingBlockLevel,blockLevel,decisionNumber,maxK,maxAlt,description) ::= <<
// <fileName>:<description>
int alt<decisionNumber>=<maxAlt>;
<decls>
<@predecision()>
<decision>
<@postdecision()>
<@prebranch()>
switch (alt<decisionNumber>) {
    <alts:{a | <altSwitchCase(i,a)>}>
}
<@postbranch()>
>>

和

/** A case in a switch that jumps to an alternative given the alternative
 *  number.  A DFA predicts the alternative and then a simple switch
 *  does the jump to the code that actually matches that alternative.
 */
 altSwitchCase(altNum,alt) ::= <<
 case <altNum> :
   <@prealt()>
   <alt>
   break;<\n>
 >>

从那里我认为我必须做的就是做我自己的函数，在调用 predict 之前将所有 altNum 放入堆栈中。所以我尝试了： /* 你 }>*/

我期待得到漂亮的小令牌 id 列表。但我并没有得到真正不同的东西。

所以我真的很迷茫，想知道是否有更简单的方法来提供此自动完成功能而无需手动完成，或者我错过了如何修改模板以添加自定义堆栈来添加规则中有不同的替代方案，因此我可以在引发异常后阅读它

非常感谢

Answer 1

很抱歉这样说，但是：不要直接使用解析器来自动完成。如果不对生成的解析器进行大量手动更改（这需要深入了解），这将无法按您的预期工作，原因有以下几个：

• 您经常有不完整的输入，除非您只有一种简单的语言，否则由于解析器的回溯性质，您经常会发现自己处于意外的规则路径中。例如，如果您在规则中有多个 alt，如果只有一个附加标记可用，则第一个 alt 将匹配，则解析器在尝试所有其他 alt 之前不会失败，它会为您提供完全不同的标记或比实际需要的更多的标记.

• 跟随集仅在错误情况下可用。但是，可能没有错误，或者有错误但位置与插入符号当前的位置完全不同（以及用户期望自动完成框的位置）。

• 后续集仅适用于您要呈现的一小部分信息（即关键字）。但是，如果您在 FROM 子句中（假设这里是 SQL 语言），通常您想显示数据库中可能的表。您不会从解析器获得此类信息，仅仅是因为解析器没有此类上下文信息。然而，你得到的是“标识符”，它可以是表、函数名、变量或类似的任何内容。

我目前处理此类问题的方法是将输入标记化并在决策树中应用领域知识。也就是说，我遍历输入标记并根据我从语法中获得的知识来决定要显示的最重要的内容。