野牛移位减少冲突，我不知道在哪里答案

【问题标题】：bison shift reduce conflict, i don't know where野牛移位减少冲突，我不知道在哪里
【发布时间】：2012-06-15 22:51:46
【问题描述】：

语法：http://pastebin.com/ef2jt8Rg y.输出：http://pastebin.com/AEKXrrRG

我不知道这些冲突在哪里，有人可以帮我解决这个问题吗？

【问题讨论】：

我不是 Bison 用户，更不用说专家了，但是如果您向下看输出的底部，您会看到各种状态以及发生减少的位置。我认为您需要查找针对单个州列出了多个班次或减少替代方案的位置。

【解决方案1】：

y.output 文件会告诉您冲突的确切位置。第一个处于状态 4，因此如果您向下查看状态 4，您会看到：

state 4

   99 compound_statement: '{' . '}'
  100                   | '{' . statement_list '}'

    IDENTIFIER      shift, and go to state 6
          :
    IDENTIFIER  [reduce using rule 1 (threat_as_ref)]
    IDENTIFIER  [reduce using rule 2 (func_call_start)]

这告诉你，在这种状态下（解析compound_statement，看到{），并查看下一个标记是IDENTIFIER，它可以做3 件可能的事情——转移标记（这将是 statement_list 的开始），减少 threat_as_ref 空生产，或减少 func_call_start 空生产。

方括号告诉您它已决定永远不执行这些操作——默认的“优先转换而不是减少”冲突解决意味着它将始终执行转换。

您的语法问题是这些空规则 threat_as_ref 和 func_call_start - 在移动 IDENTIFIER 之前需要减少它们，但是为了知道它们是否有效，解析器需要查看标记在标识符之后。 func_call_start 只有在这是函数调用的开始时才应该减少（这取决于在 IDENTIFIER 之后有一个(。）所以解析器需要更多的前瞻来处理你的语法。在您的具体情况下，您的语法是 LALR(2)（2 个标记前瞻就足够了），但不是 LALR(1)，所以野牛无法处理它。

现在你可以通过去掉那些空规则来修复它——func_call_start 根本没有任何动作，threat_as_ref 的动作可以移动到variable 的动作中，但如果你想要那些未来可能会出现问题的规则。

【讨论】：

如果其他人遇到这种情况，-v 标志会创建 .output 文件

【解决方案2】：

(1) 我至少看到一件事看起来很奇怪。您为expression_statement 制作的作品与postfix_statement 的作品相似，但并不完全相同。他们没有 '(' 和 ')' 标记：

expression_statement
    : ';'
    | expression ';'
    | func_call_start IDENTIFIER { ras_parse_variable_psh($2); aFree($2); } func_call_end ';'
    | func_call_start IDENTIFIER { ras_parse_variable_psh($2); aFree($2); } argument_expression_list func_call_end ';'
    ;

因为expression 可以是primary_expression，也可以是IDENTIFIER，并且因为func_call_start 和func_call_end 是epsilon (null) 产生式，当出现输入时

foo;

解析器必须决定是否应用

expression_statement : expression ';'

或

expression_statement :  func_call_start IDENTIFIER { ras_parse_variable_psh($2); aFree($2); } func_call_end ';'

(2) 另外，我不确定这一点，但我怀疑 epsilon 非终端 threat_as_ref 可能会给您带来一些麻烦。我没有追查过它，但可能存在解析器必须决定某事物是variable_ref 还是variable 的情况。

【讨论】：