[antlr-interest] ArrayIndexOutOfBoundsException

[Gavin Lambert]

At 21:53 2/02/2008, Steve Bennett wrote:
 >
 >Good thoughts, but it doesn't seem to be that here, as it's
 >failing mid sentence (well short of the EOF), and it's
 >bombing even without hte reference to input.LA(). Any others
 >ideas?

I thought you said that when you removed the predicate the problem 
went away?

Anyway, to requote the original full exception you posted earlier:
 >Exception in thread "main"
 >java.lang.ArrayIndexOutOfBoundsException: -1
 >	at org.antlr.runtime.DFA.predict(DFA.java:44)
 >	at mediawiki1Parser.inline_text(mediawiki1Parser.java:13618)
 >	at 
mediawiki1Parser.header_simple_text(mediawiki1Parser.java:16669)
 >	at mediawiki1Parser.header3(mediawiki1Parser.java:5423)
 >	at 
mediawiki1Parser.synpred19_fragment(mediawiki1Parser.java:19872)
 >	at mediawiki1Parser.synpred19(mediawiki1Parser.java:20998)
 >	at mediawiki1Parser.headerline(mediawiki1Parser.java:4238)
 >	at 
mediawiki1Parser.synpred3_fragment(mediawiki1Parser.java:19604)
 >	at mediawiki1Parser.synpred3(mediawiki1Parser.java:21158)
 >	at mediawiki1Parser.line(mediawiki1Parser.java:1295)
 >	at mediawiki1Parser.article(mediawiki1Parser.java:915)
 >	at mediawiki1Parser.start(mediawiki1Parser.java:299)
 >	at __Test__.main(__Test__.java:14)

So, it's trying to parse a "line".  In doing that, it's calling 
ahead through a syntactic predicate which ends up involving 
"headerline", which in turn has another syntactic predicate 
leading to "header3", then "header_simple_text", and finally 
"inline_text".  Presumably the problem lies somewhere in that 
chain of rules -- and not necessarily at the end.  (I know you've 
changed things since this particular exception, so you're getting 
it somewhere else now, but you can follow the same line of 
reasoning on the full trace of the exception you're getting 
now.)  The main thing is that you can tell from the trace which 
rules are "locked" and which ones are "speculative" based on 
whether they appear before or after a synpred call, and from that 
you might be able to tell whether it's going down the wrong path.

 >literal_right_bracket
 >         { !prohibit_literal_right_bracket &&
 >(prohibit_literal_link_end <= 0 || input.LA(2)!= RIGHT_BRACKET) 
}?
 >         RIGHT_BRACKET;
[...]
 >Changing the rule to either of the following prevents the
 >exception occurring (but with incorrect behaviour):
[...]
 >literal_right_bracket
 >        { !prohibit_literal_right_bracket &&
 >(prohibit_literal_link_end <= 0 || input.LA(2)!= 
RIGHT_BRACKET)  }?
 >=> '&';

You actually made two changes here -- you changed the character it 
was matching and you changed it to a gated predicate.  Have you 
tried the original version but as a gated predicate instead?  (It 
looks like it ought to be a gated predicate anyway.)