GNU Info

Info Node: (bison.info)Tie-in Recovery

(bison.info)Tie-in Recovery


Prev: Lexical Tie-ins Up: Context Dependency
Enter node , (file) or (file)node

Lexical Tie-ins and Error Recovery
==================================

   Lexical tie-ins make strict demands on any error recovery rules you
have.  Note: Error Recovery.

   The reason for this is that the purpose of an error recovery rule is
to abort the parsing of one construct and resume in some larger
construct.  For example, in C-like languages, a typical error recovery
rule is to skip tokens until the next semicolon, and then start a new
statement, like this:

     stmt:   expr ';'
             | IF '(' expr ')' stmt { ... }
             ...
             error ';'
                     { hexflag = 0; }
             ;

   If there is a syntax error in the middle of a `hex (EXPR)'
construct, this error rule will apply, and then the action for the
completed `hex (EXPR)' will never run.  So `hexflag' would remain set
for the entire rest of the input, or until the next `hex' keyword,
causing identifiers to be misinterpreted as integers.

   To avoid this problem the error recovery rule itself clears
`hexflag'.

   There may also be an error recovery rule that works within
expressions.  For example, there could be a rule which applies within
parentheses and skips to the close-parenthesis:

     expr:   ...
             | '(' expr ')'
                     { $$ = $2; }
             | '(' error ')'
             ...

   If this rule acts within the `hex' construct, it is not going to
abort that construct (since it applies to an inner level of parentheses
within the construct).  Therefore, it should not clear the flag: the
rest of the `hex' construct should be parsed with the flag still in
effect.

   What if there is an error recovery rule which might abort out of the
`hex' construct or might not, depending on circumstances?  There is no
way you can write the action to determine whether a `hex' construct is
being aborted or not.  So if you are using a lexical tie-in, you had
better make sure your error recovery rules are not of this kind.  Each
rule must be such that you can be sure that it always will, or always
won't, have to clear the flag.


automatically generated by info2www version 1.2.2.9