[antlr-interest] Bug? Invalid Java code generated

Sam Barnett-Cormack s.barnett-cormack at lancaster.ac.uk
Fri Mar 6 10:12:27 PST 2009


Andreas Meyer wrote:
> Sam Barnett-Cormack schrieb:
>> Hi all
>>
>> The attached grammar (which you're probably all tired of) generates 
>> Java code with an error in. I've checked, and the error isn't in a 
>> copy action or predicate - it's in the expansion of $text in a parser 
>> predicate. I don't know if I've used $text incorrectly, because I'm 
>> using it as I understand the documentation says to (including the 
>> ANTLR book).
>>
>> The error is:
>>
>> retval cannot be resolved
>>
>> on: ASN_1Parser.java
>> line: line 17279
>>
>> The generated function in question is:
>>
>> // $ANTLR start synpred26_ASN_1
>>     public final void synpred26_ASN_1_fragment() throws 
>> RecognitionException {
>>         // /home/sdb/workspace/asn.1-parse/grammars/ASN_1.g:583:44: ( 
>> nameForm {...}?)
>>         // /home/sdb/workspace/asn.1-parse/grammars/ASN_1.g:583:44: 
>> nameForm {...}?
>>         {
>>         pushFollow(FOLLOW_nameForm_in_synpred26_ASN_13890);
>>         nameForm();
>>
>>         state._fsp--;
>>         if (state.failed) return ;
>>         if ( 
>> !((isStandardOIDName(input.toString(retval.start,input.LT(-1))))) ) {
>>             if (state.backtracking>0) {state.failed=true; return ;}
>>             throw new FailedPredicateException(input, 
>> "synpred26_ASN_1", "isStandardOIDName($text)");
>>         }
>>
>>         }
>>     }
>> // $ANTLR end synpred26_ASN_1
>>
>> The rule from the grammar (whole thing attached) is:
>>
>> objIdComponents options{backtrack=true;} : nameForm 
>> {isStandardOIDName($text)}? | numberForm | nameAndNumberForm | 
>> definedValue ;
>>
>> If this isn't a bug, can someone explain how to pass a function called 
>> in a predicate the text matched so far? If this is a bug, anyone have 
>> a workaround? Please. Thanks!
> 
> I'm currently not 100% sure of the exact syntax, but why dont you use 
> something like $nameForm.text ? This is the simplest workaround for the 
> problem you showed. Or do you have other cases where you need to easily 
> access the $text of a lot of rules?

Yeah, that's what I just figured from looking at examples - it's not 
made completely clear, and if it weren't for the fact that it generates 
*some* code that's *almost* right, I might have realised it sooner.

Of course, I can't try it right now, because that computer has decided 
it doesn't want to play...

-- 
Sam Barnett-Cormack


More information about the antlr-interest mailing list