1

What happen is there is a specific case where after analyzing the AST i will know if there is an error or not when the rule is finished. I tried yyerror("blah") with no luck.

Because i cant tell it there is an error it finishes another rule and now has a reduce/reduce conflict. This is annoying because i KNOW when one of them is invalid without looking at the other but the user has to suffer bc i dont know how to say ignore this branch bc its invalid

How do i fix this problem?

2 Answers2

2

You want YYERROR not yyerror -- putting YYERROR in an action causes the parser to make the action a syntax error, and go into error recovery mode (if you have any error recovery actions in your parser -- otherwise this is more or less equivalent to YYABORT). yyerror is a routine that bison calls with error messages -- the default implementation is to print the error message -- but is has nothing (specifically) to do with parsing or syntax errors.

Note that this has no relation to any reduce-reduce (or shift-reduce) conflicts -- conflicts are not errors, they are things in your grammar that make it not-LALR(1), so that the bison generated parser can't reliably recognize it.

Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
  • Though one should note that if you have a reduce/reduce conflict in a state that is never reachable (because your use of `YYERROR` prevents it), then it won't be a problem. – templatetypedef Jul 23 '11 at 23:08
  • Thanks it solved my problem! (although i doesnt change the r/r error count which i expect and kind of prefered) –  Jul 23 '11 at 23:54
0

You need to create a syntax which is free of reduce/reduce conflicts

Soren
  • 14,402
  • 4
  • 41
  • 67
  • This doesn't answer the question, and it might be impossible to do this (for example, the C++ grammar is not LALR(1)). The question is how to use context-sensitive information to determine how to make the parser never try doing a reduction that couldn't possibly be correct. – templatetypedef Jul 23 '11 at 22:51