lemon + re2c没有得到正确的规则解析

时间:2016-04-05 06:33:50

标签: c++ parsing lemon

这是我的柠檬解析器语法

%nonassoc IMPLICATION.
%nonassoc PERIOD.
%nonassoc NEWLINE.
%nonassoc END.
%nonassoc STRING.

program ::= in END.
in ::= .
in ::= in rule NEWLINE.
in ::= in rule.
rule ::= STRING(A) IMPLICATION STRING(B) PERIOD. {cout<<A->token<<endl; cout<<B->token<<endl;}

我的输入字符串是

p<-body1.
q<-body3.

我期待输出

p
body1
q
body3

但我得到输出为

q
q
\n (Empty line here)
\n (Empty line here)

我确信我正在以正确的顺序传递令牌,并且我已经验证过,因为解析器会在输入错误时抛出语法/解析器错误。

这是我用来将标记传递给解析器的代码

do
{
    token = lexer.scan(); // returns an int with the type of token 
    Token* t = new Token(lexer.getTokenValue().c_str());

    lpmlnParse(pParser, token, t);
}while(token != PARSE_TOKEN_END);

我不知道出了什么问题。有人能指出我正确的方向。

1 个答案:

答案 0 :(得分:1)

这仍然是猜测,因为没有迹象表明扫描程序是如何工作的,或者lexer.getTokenValue()的值是什么,或者Token构造函数如何使用它的参数。

但是让我们假设lexer对象包含一个私有std::string成员,该成员在扫描每个令牌后分配给匹配的文本:

struct lexer {
  // ...
  int scan() {
    int toke;
    const char* start = current_;
    /* re2c stuff */
    tstring_.assign(start, current_ - start);
    return toke;
  }
  const std::string& getTokenValue() const {
    return tstring_;
  }
  std::string tstring_;
  const char* current_;
};

并假设Token包含const char*成员(而不是std::string):

struct Token {
  explicit Token(const char* s) : str_(s) {}
  const char* str_;
}

这至少可以解释观察到的行为。

每次连续调用lexer.scan()都会覆盖tstring_的内容。 (在一般情况下,std::string::assign可能会重新分配内部字符数组,但由于现代C ++库使用短字符串优化,并且示例代码中的所有标记都是短字符串,因此这不会发生。)

由于std::string::c_strToken构造函数都没有复制字符,因此最终结果是新创建的Token有一个指向可变内部缓冲区的指针。扫描过程中覆盖(或更糟,删除)。

因此,Token的字符串值在第一次创建Token时的减少操作中被观察到时会有所不同。

这仍然不足以解释为什么q被规则打印出来,可能会减少p->body1.

bison不同,lemon解析器不会尝试优化前瞻。 bison - 生成的解析器将在请求前瞻标记之前执行缩减,前提是不需要前瞻标记来决定是否减少或移位。相比之下,lemon生成的解析器仅在超前令牌可用时减少。在这种情况下,生成rule ::= STRING(A) IMPLICATION STRING(B) PERIOD.的减少不依赖于PERIOD之后的令牌,但柠檬解析器仍将等待下一个令牌。

从语法中,可以预期下一个标记是NEWLINE,但在这种情况下,输出应显示两个换行符(或四个空白行,因为语义操作也会打印换行符)。由于情况并非如此,我们可能会推测词法分析器正在跳过换行符而不是返回NEWLINE标记。如果是这种情况,语法仍然有效,因为NEWLINE令牌是可选的(in rulein rule NEWLINE都是有效的右侧)。然后,先行令牌将是以下STRING令牌,它将是q。并且q->body3.之后的前瞻标记将是END,而不是NEWLINE,因此相应的标记字符串将为空,而不是换行符,这似乎是合理的。

显然,如果上述所有推测都有效,那么解决方案就是制作令牌字符串的副本,例如将const char* str_;替换为std::string str_;对象中的Token 。在这种情况下,用const char*构造函数或甚至简单的const std::string&构造函数替换std::string构造函数是合理的,从而避免使用std::string::c_str()的必要性。