[antlr-interest] Suppressing spurious warnings

[Gavin Lambert]

At 02:31 28/02/2008, Steve Bennett wrote:
 >[00:15:28] warning(105): C:\antlr\mediawiki12.g:996:12: no lexer 

 >rule corresponding to token: PRE_OPEN
 >
 >There is no lexer rule but I'm setting it explicitly:
 >...
 >    | (PRE_OPEN_ACTUAL) => PRE_OPEN_ACTUAL { $type=PRE_OPEN;
 >in_pre=true; in_noparse=true;}
 >...

You can suppress the warning by removing PRE_OPEN from the tokens 
block and adding a fragment rule for it instead:

fragment PRE_OPEN: ' ';

The actual contents of the rule are unimportant (since you're 
never actually calling it); they can't be empty, though.  Usually 
you'd either put an obvious placeholder like above or put a simple 
string constant describing how it ought to look in the end (eg. 
'<pre>').

 >[00:27:43] warning(200): mediawiki12.g:346:4: Decision can match 

 >input such as "HYPHEN" using multiple alternatives: 1, 2

At present, the only way to remove these warnings is to rewrite 
your grammar to remove the ambiguity.  Note that while ANTLR often 
does the right thing anyway, you can't just assume that.  You 
should always either rewrite the grammar or test its behaviour 
thoroughly.  Or both.

 >[00:27:45] warning(205): mediawiki12.g:356:4: ANTLR could not
 >analyze this decision in rule table_multiline_header_cell; 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.

True left-recursion is fatal to ANTLR, so must be corrected.

 >As I've reported earlier, in my situation adding the option 
*and*
 >a syntactic predicate didn't even help, so the warning isn't 
much
 >use.

The suggestion in the message is a bit misleading -- since ANTLR 
automatically discards predicates that it thinks are unnecessary 
(because they have no alts), simply adding a predicate isn't good 
enough.  You may need to combine it with some other rules.

I have yet to see a case where ignoring this warning is a good 
idea.