How to avoid conflicts when generating IR codes in yacc? - c

Question

%nonassoc NO_ELSE
%nonassoc ELSE
stmt_conditional
: IF '(' expr { show_if_begin($3); } ')' stmt_compound { show_if_end(); } %prec NO_ELSE
| IF '(' expr { show_if_begin($3); } ')' stmt_compound { show_if_else(); } ELSE stmt_compound { show_if_end(); }
Since stmt_compound will generate IRs, show_if_begin() should be in front of stmt_compound. However, this will cause reduce/reduce conflicts in yacc. How to solve this problem?
EDITED
This is what I've tried, but it didn't work.
stmt_conditional
: stmt_cond_if { show_if_end(); } %prec NO_ELSE
| stmt_cond_if { show_if_else(); } ELSE stmt_compound { show_if_end(); }
;
stmt_cond_if
: IF '(' expr { show_if_begin($3); } ')' stmt_compound

Answer 1

The reason why your variant doesn't work is that you need infinite lookakead to distinguish between the two kinds of if statement. When your parser looks at an IF token, it has no idea whether it will see ELSE or NO_ELSE, or when to expect one if those, but it has to decide where to shift now in order to process the expression.
The solution is to factor out more common stuff so that the decision is made exactly when it's needed.
stmt_conditional
: stmt_cond_if { ... } else_part
;
else_part
: %prec NO_ELSE
| ELSE stmt_compound { ... }
;
In theory, the parser generator should be able to refactor these rules automatically, but code blocks in the middle of the rule prevent yacc from doing so. Even empty code blocks in otherwise identical rules prevent them from being flattened out. That's because yacc sees the contents of code blocks as black boxes. It has no idea what these actions mean and has to assume they all might mean different things, even if the text is identical.
You can verify that when you remove the actions, the conflict disappears. Of course a yacc grammar without actions is less useful.
Naturally this factoring-out unifies your actions for THEN that originally were distinct for else and no-else variants. There is no way around this. You have to write an action that is good for both cases.
Edit In practice, such code blocks are handled by yacc by creating a new invisible rule and a new non-terminal for each mid-rule action. Quoth the yacc page:
Actions that do not terminate a rule are actually handled by Yacc by manufacturing a new nonterminal symbol name, and a new rule matching this name to the empty string. The interior action is the action triggered off by recognizing this added rule.
It's these invisible rules that actually cause conflicts in your grammar. So another solution would be to leave the rules proper as is, but move actions to the end of their respective rules. I personally still like to factor out common parts manually. -- end edit.
Without %prec there would be a shift/reduce warning, because
if (x)
if (y)
do_something
else
do_something_else
is ambiguous: when the parser sees else, it doesn't know whether it belongs to the inner if (shift) or the outer one (reduce). The default behaviour is to shift, which is what we normally want. %prec makes this explicit and eliminates the warning.
Note this still may interfere with the rest of your grammar. If you can change your syntax I would suggest switching from C-like compound-statement-based syntax to an ENDIF-based one as found in e.g. Ada.