[antlr-interest] Bug with predicates and DFAs?

[Braun, Kevin T]

Ter,

Just to make sure I was clear, it is the input.LT(1).getText() part of
the predicate that causes a problem when hoisted, since the DFA is using
an IntStream and not a TokenStream.  Since you mention "function of
input symbols", I wasn't sure if I got my point across or not.
 
Thanks,
Kevin

Date: Fri, 17 Aug 2007 13:44:05 -0700
From: Terence Parr <parrt at cs.usfca.edu>
Subject: Re: [antlr-interest] Bug with predicates and DFAs? (ANTLR
	3.0)
To: antlr-interest Interest <antlr-interest at antlr.org>
Message-ID: <50B52412-A223-4E78-842B-69FC73FF909E at cs.usfca.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Yes, predicates can be hoisted outside of their defining rule. You  
should assume that it is safe only to use expressions that are a  
function of input symbols or globally visible values such as fields  
and methods.
Ter


On Aug 17, 2007, at 11:02 AM, Braun, Kevin T wrote:

> Hi,
>
> I tried using this rule:
>
> keywordSet
>
>             :           {setCanBeId && input.LT(1).getText().equals 
> ("set")}? IDENT;
>
>
>
> in order to allow "set" to appear either as a keyword or as an  
> identifier.  The rule where keywordSet is used ends up being  
> involved in an LL(*) decision.  In the generated parser, the code  
> in the DFA has a method specialStateTransition declared as:
>
> public int specialStateTransition(int s, IntStream input) throws  
> NoViableAltException
>
>
>
> The predicate from keywordSet ends up in this  
> specialStateTransition method (I guess that's the predicate  
> hoisting), but this results in invalid code: inside this method,  
> input is an IntStream and IntStream.LT() returns an int, not a  
> token object.  That makes input.LT(1).getText() invalid.
>
>
>
> Regards,
>
> Kevin
>
>