[il-antlr-interest: 24142] Re: [antlr-interest] problem in displayRecognitionError() in antlr2baserecognizer.c

[Jim Idle]

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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to il-antlr-interest@googlegroups.com To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en -~----------~----~----~----~------~----~------~--~---

List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe: 
http://www.antlr.org/mailman/options/antlr-interest/your-email-address