[antlr-interest] Known bug for antlr v3.2?

[David-Sarah Hopwood]

loic.lefevre at bnpparibas.com wrote:
> Hello,
> while testing some gated semantic predicate:
> 
> address
> @init{int n=1;}:
>         ( {n<=12}?=> c=CHAR {n++;} )+
>         {
>             // check for address validity
>             final String t = $address.text;
>             if( t.length() != 12 ) {
>                 throw new InvalidSWIFTBlock1AddressException( t, 
> $c.getLine(), $c.getCharPositionInLine() );
>             }
>         }
>         ;
>         catch[MismatchedTokenException mte] { throw new 
> InvalidSWIFTBlock1AddressException( mte.token.getText(), mte.line, 
> mte.charPositionInLine ); }
> 
> 
> I encoutered problem after Java source generation:
[...]
> SWIFTMTParser.java:865: cannot find
>  symbol
> symbol  : variable n
> location: class 
> com.bnpparibas.acetp.foxhound.spec2009.parser.SWIFTMTParser.DFA1
>                         else if ( (LA1_23==12) && ((n<=12))) {s = 14;}

This happens when a predicate referring to a local variable is hoisted
into a DFA class. You can work around it by making 'n' a field of the
parser class (preferably with a more distinct name); then, the DFA1
instance will be able to refer to it because DFA1 is an inner class
of the parser.

Note that in general this might not work if there are recursive
invocations of the same rule, although that shouldn't be a problem
in this particular case (since <address> only refers to <CHAR>). There
are similar hazards if you reuse the field across rules.

Incidentally, for this example it *might* be simpler to eliminate n
and rely on the length check in the action -- this may consume
additional CHARs, but that's not necessarily a problem, given that
the producer of the input may have intended those CHARs to be part
of the address.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20091203/6aaa2674/attachment.bin