[antlr-interest] Bug with predicates and DFAs?
Braun, Kevin T
Kevin.Braun at fnis.com
Mon Aug 20 06:45:24 PDT 2007
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
>
>
More information about the antlr-interest
mailing list