[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: few questions
From: |
Hans Aberg |
Subject: |
Re: few questions |
Date: |
Wed, 28 Jul 2004 01:38:12 +0200 |
At 11:47 -0700 2004/07/27, Aleksey Perfilov wrote:
>Hi, guys. I need help with improving my syntax error messages. Right
>now I just have standard bison error handling where it looks at possible
>tokens and says <token> expected. Few quetions, if you don't have
>time to read all, please answer just on one or two of them.
>question 1: I am not exactly clear on contents of yytable, what does it
>mean "portions for different uses" ? What do those portions contain
>and in what format?
The best way figure that out is to read the parser code, and see how it is
used. There is no documentation, and people general do not have time to go
in and figure that for you.
question 2: if I put an error token in a rule that doesn't have a closing
token like this stmnts: /* empty string */
> | stmnts '\n'
> | stmnts exp '\n'
> | error is error token going to match all of the remaining
>output if syntax error occurs?
Read the Bison manual on how error recovery works. Roughly, it pops the
parser stack, until it finds an error recover symbol, and tries to continue
there on. The best way is to experiment with that in practise: When an
error token is found, LALR(1) relative LR(1) may add a few more actions
before an error is initiated. So you can't be too sure to get the effects
you want.
>question 2: what if I have a mid rule where I decide that something's
>wrong and want to ignore the whole expression expr : part1 { some
>checks here } part2 part3 part4 part5 How can I go about it?
The midrule actions are implemented by adding a new, anonymous, grammar
variable with empty expansion and the indicated midrule action. So the
effects will always be same as of that implementation.
>question 3: If I get an error in lexer, for example closing comment w/o
>opening comment, how can I get the parser to ignore the token or maybe
>a serie of tokens?
Only by making sure that no error tokens are fed to the parser.
>question 4: In Bison code there is YYFAIL macro that goes to yyerrlab:
>Is it the default action when an error is encountered?
The parser code says:
#define YYERROR goto yyerrlab1
/* Like YYERROR except do call yyerror. This remains here temporarily
to ease the transition to the new meaning of YYERROR, for GCC.
Once GCC version 2 has supplanted version 1, this can go. */
#define YYFAIL goto yyerrlab
So when YYERROR is used, the error reporting must be done explicitly:
yyerror("...");
YYERROR;
YYFAIL uses the Bison default error reporting mechanism.
>question 5: For example if I have a piece of program like this: a=1
>b=2; when parser reads "b" it errors, I print "missing semicolon" but
>then I want to continue parsing. How do I put back "b" so that b=2; is
>parsed successfully.
Good error recovery is a research topic. So I think are more likely
approach is to report the error, and skip forward to a point where easy
error recovery can be made.
Hans Aberg
- few questions, Aleksey Perfilov, 2004/07/27
- Re: few questions,
Hans Aberg <=