[antlr-interest] problem in displayRecognitionError() in antlr2baserecognizer.c

[Xie, Linlin]

Hi Jim,

 

Thanks for your reply. We finally figure out that large number of
expecting is actually -1, which is EOF. I guess this would rule out the
possibility of a bug in antlr, if we don't speak of the appropriateness
of the message. In the use case I mentioned in my last email, I would
think start(Rule2), start(Rule3) and ; all should be the expected
tokens, instead of EOF. Do you think if there is anything antlr can do
to improve the error messages to make them more relevant? Or should I
improve my grammar to get more appropriate error messages, and how?

 

Also I can see when the displayRecognitionError() checks the recognizer
type, it only considers either parser or tree parser, why is lexer not
considered here? I can see that a lexer error is considered a No Via Alt
parser exception, but there is still lexer error report from antlr,
where can I find the lexer error report code? Or how can I intercept the
lexer error like I do with the parser error report? 

 

Many thanks!

Linlin

 

 

 

From: Jim Idle [mailto:jimi at temporal-wave.com] 
Sent: 09 June 2009 17:25
To: Xie, Linlin
Cc: antlr-interest at antlr.org; Fitt, Andrew; Hamid, Nusrat
Subject: Re: problem in displayRecognitionError() in
antlr2baserecognizer.c

 

Xie, Linlin wrote: 

Hello Jim and all,

 

I wonder if there is any bug in antlr setting the "expecting" member
variable of struct "ANTLR3_EXCEPTION". The following is what I find out
while assigning my own error processing function to antlr's recognizer's
reportError function pointer:

 

For my grammar definition like:

"Query: Rule1 Rule2? Rule3? ; EOF"

And for my test case that has a malformed syntax, which matches Rule1,
but the rest doesn't match either Rule2 or Rule3, through debugging, I
find that the parser then tries to match with ";", of course it doesn't
match ";" again, then it tries to report error and recover. 

 

In the antlr's error reporting (I did it by copying the content of
displayRecognitionError() to my own error processing function), the
"expecting" variable should point to the position of ";" as that's what
it tries to match. But it shows that the expecting is a very large
number that can't possibly be within the range of the

Hi - the routines in the runtime are just examples. You are expected to
make a copy of them and install your own routines. Note that the
expecting member of the token is not always a valid token number. For
instance you have to check it for being -1, which means it was expecting
EOF, which is probably what it is expecting in your grammar above right?

            if    (ex->expecting == ANTLR3_TOKEN_EOF)
            {

Also, for some exception types, expecting is not a valid field. The
default routines should show you that as not all exceptions access
expecting. Finally, for some exceptions, you don't get a token number,
but a bit set, from which you must extract the set of tokens that coudl
have matched. This is a possibility here because your possibilities are
start(Rule2) & start(Rule3) & ';'. In the code that processes
ANTLR3_MISMATCHED_SET_EXCEPTION, you can see how to deal with the bit
set.

So, if your expecting code is not -1, then it is a bitmap in all
likelihood.





vector "TokenNames", however as C doesn't have exception handlings, the
print out is "null", if without looking carefully, it seems to be no
problem at all. But what I'm trying to do in my own function is to read
out the error information from antlr exception and output it into
standout output in C++, that's how an exception is thrown in C++ that
leads me to the problem. I did some probing of the antlr code, and think
it could be a bug when antlr sets the "expecting" variable in case of
such an error.  Also I find that the exception variable has a
nextexception pointer which points to another exception variable

The nextException isn't used by the default error reporting, I just
included it in case anyone thought it useful. 

Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20090611/905f1302/attachment.html