[antlr-interest] 3.0 resetStateNumbersToBeContiguous error

Terence Parr parrt at cs.usfca.edu
Wed Jun 28 09:12:11 PDT 2006


On Jun 28, 2006, at 12:15 AM, Thomas Brandon wrote:

> I have been trying to get a grammar for C going in Antlr 3 but keep  
> running errors in resetStateNumbersToBeContiguous (max state num !=  
> max renumbered state) for various rules. I have looked and there  
> does not seem to be any left recursion in the rule, I'm pretty sure  
> all possible recursive paths include a terminal. What exactly  
> causes this error? Are there any hints for diagnosing the cause of  
> the error? As analysis has failed it looks like most of the really  
> nice information you'd get from Antlr to diagnose such issues is  
> unavailable. 3.0b1 adds a nicer error message but does not seem to  
> provide much more information.

Hi Thomas, that error is a code gen issue using my new table-based  
approach.  Can you send me the grammar directly?


> I have managed to somewhat chart the issues but largely through  
> trial and error, removing rules I suspect might cause troubles and  
> rewriting the grammar a number of times in different ways and  
> seeing where it falls apart. Are there any better methods?

Well, the analysis usually only fails when you have rules like:

a : foo ...
   | foo ...
   ;

where foo is huge or recursive.  It then backs off to LL(1) by  
dfault...i'm adding a backtrack option that will backtrack for any  
alt in the decision that is a problem.

> I understand you can set a fixed k and resolve the issue that way  
> but this seems like a non-optimal solution as I think some of the  
> ambiguities should be resolvable without backtracking (especially  
> the main statement rule which currently requires fixed lookahead +  
> a predicate to distinguish varDef and funcDef rules).

Generally they are...my java statement rule is super complicated.

> Also, what effect does setting a fixed lookahead on one rule have  
> on the analysis of calling rules?

It only affects the set of tokens used to predict which alt gets  
applied not the calling of rules.

> And, specifically, has anyone looked at doing a C grammar in Antlr 3?

If you send it to me, we should have it built within a few hours!

> Oh yeah, and wow, Antlr 3 rocks.

Thanks!  I suspect now that people are really using it we'll find a  
few nasty surprises that I'll raceto fix by 3.0 final.  I'll look  
into your error today though.

Ter


More information about the antlr-interest mailing list