Copyright (C) 2000-2012 |
GNU Info (bison.info)Tie-in RecoveryLexical 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 |