Re: Yacc/Bison - what semantic actions to take on a parse error

On May 23, 12:19 pm, James Harris <james.harri...@gmail.com> wrote:


> Yacc etc allow the special "error" keyword to be used in rules to aid
> error recovery. Where those rules are there to generate a node of a
> tree and there has been a parse error what should one tell Yacc to do?


...


> [My standard answer is that the error token is mostly useful for
> resynchronizing to try to find some more syntax errors, but that it's
> a losing battle to try to do much what you've parsed.


I wasn't thinking about using the parse tree after the parse phase so
much as just completing the parse.


An example may help illustrate. Say were defining a node type X where
there is nothing special about that node type. We might have a grammar
construct something like the following. I'll use quotes "..." to
indicate descriptive text.


%type <X_type> X
X
    : "a normal X" ';' { $$ = Xnode("specific data"); }
    | error ';' { ACTION; }
;


The Xnode call constructs a node. The X production expects $$ to be
set to a node of the given type.


The issue is that the error production cannot create a meaningful node
so what actions to replace ACTION are appropriate? Here are some
options.


* Create an X node with dummy values. That would satisfy the type
checking.
* Set $<err_msg>$ = "invalid X node"
* Braces but no action, i.e. {}
* No action clause so default to $$ = $1;
* Some combination of YYERROR; and yyerror();


John, you'll know but for anyone who isn't aware of these options
those for Bison are shown at


    http://www.gnu.org/software/bison/manual/html_node/Action-Features.html


So, which option is 'best'? Or should we just ignore a type mismatch
error?


James
[You already know you ran into a syntax error, so I'd think that type
checking is more likely to produce an error cascade than something
useful. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.