[antlr-interest] Bug in lookahead DFA?

Terence Parr parrt at cs.usfca.edu
Tue Dec 11 14:32:57 PST 2007


Harmon, this is indeed a bug. worse, in 3.1beta it disappears and  
builds bad DFA!  Yikes.  I've seen this before; added to my existing  
bug:

http://www.antlr.org:8888/browse/ANTLR-178

I'll fix for 3.1

Ter
On Nov 14, 2007, at 9:36 AM, Harmon Nine wrote:

> Hi.
>
> I’m trying to write a parser for MatLab (without objects, classes,  
> or structs) and am coming across some peculiar behavior.  A portion  
> of this grammar that results in this behavior is at the end of this  
> message.
>
> In this grammar, I’m using a syntactic predicate to differentiate  
> between an assignment and expression-evaluation statements (see the  
> “statement” rule below).  Antlr accepts the parser definition  
> without error.
>
> The problem occurs when the parser attempts to parse a rather simple  
> file:
> y(1) = 0
> y(1)
>
> That is, it gives the error
>
> line 1:5 no viable alternative at input ‘=’
>
> Perhaps there is an error in the parser definition, but the peculiar  
> thing is that when, on the “statement” rule, I reduce “k” to 2, i.e.
>
> statement:
> options {
>   k=2;
> }
>             : …
>
> The parser works correctly.
>
> I also tried k at various other values.  When it is set at a value  
> of 10, I get the following message:
>
> ANTLR Parser Generator  Version 3.0.1 (August 13, 2007)  1989-2007
> warning(205): DFABug.g:37:2: ANTLR could not analyze this decision  
> in rule statement; often this is because of recursive rule  
> references visible from the left edge of alternatives.  ANTLR will  
> re-analyze the decision with a fixed lookahead of k=1.  Consider  
> using "options {k=1;}" for that decision and possibly adding a  
> syntactic predicate.
>
> The warning message isn’t really applicable, as the rule is not  
> recursive and already has a syntactic predicate.
>
> Is this normal behavior?   I.e. when using syntactic predicates, is  
> it normal to have to give “k” a small finite value to get the  
> lookahead to work properly, rather than simply to enhance efficiency?
>
> If not, how does one submit a bug report?
>
>
> Here’s the grammar:
> parser grammar DFABug;
>
> options {
> //  language=C++;
>   tokenVocab=DFABugTokens;
>   output=AST;
> }
>
> delimiter
>         :       null_lines empty_lines?
>         |       empty_lines
>         ;
>
> null_lines
>         :       null_line+
>         ;
>
> null_line
>         :       empty_lines? ( COMMA | SEMI )!
>         ;
>
> empty_lines
>         :       line+
>         ;
>
> line    :       ( COMMENT | NEWLINES )!
>         ;
>
> statement_list
>         :       statement ( delimiter statement )* delimiter?
>         ;
>
> statement
> options {
>   k=2;
> }
>       :     (reference ASSIGN)=> reference ASSIGN^ expr
>         |       expr
>       ;
>
> expr  :     reference
>       |     INTEGER
>       |     DOUBLE
>       |     IMAGINARY
>       |     TEXT
>       ;
>
> reference
>       :       IDENTIFIER^ LPAREN! argument_list RPAREN!
>         ;
>
> argument_list
>         :       expr ( COMMA! expr )*
>         ;
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20071211/f83b5a1c/attachment-0001.html 


More information about the antlr-interest mailing list