[antlr-interest] Serious Bug when using BitSetgeneration

[Terence Parr]

On Nov 9, 2005, at 8:29 AM, Olivier Dragon wrote:

> On Tue, Nov 08, 2005 at 09:58:06AM -0800, Terence Parr wrote:
>> Hi.  Yes, that does seem to say there is a bug.  Note that I cannot
>> reproduce this bug.  I added an empty alt and I still get correct  
>> code.
>
> Could this be related to a bug I reported a few months ago?
>
> These are the threads online (spans two months). Unfortunatly mailman
> doesn't seem to deal with attachments very well. If you don't keep  
> your
> own archive I still have my simple test case, and could resend it.
>
> http://www.antlr.org/pipermail/antlr-interest/2005-July/ 
> 013231.html
> http://www.antlr.org/pipermail/antlr-interest/2005-August/ 
> 013270.html
>
> I never got a reply about it so I don't know if it was fixed.

Hi Oliver, I believe it is correct behavior you are seeing:

		 // avoid tokenizing the . from an operator (eg. "1.eq.2")
		('.' (NUM | EXPON | ~('n'|'a'|'o'|'e'|'x'|'l'|'g'|'t'|'f')))=>
		'.' (NUM)* (EXPON)?   // 123. or 123.456
		{_ttype=RCON;}

First, the => pred is totally unnecessary and antlr removes it:

	switch(LA(1)) {
	...
		case '.':
		{
			match('.');


The code it generates seems correct.  Can you tell me what path  
through the code seems bad?

If it is this:

			if ((LA(1)=='d'||LA(1)=='e')) {
				mEXPON(false);
			}
			else {
			}

where the else is blank...don't worry.  That is correct.  It is  
saying any char will work other than the EXPON:

(EXPON)?

Ter