[antlr-interest] Advanced questions and proposals

[Ric Klaren]

Alexey Demakov wrote:
> I'm trying to improve my parser (and ANTLR skills :) ) and have the following questions:
> 
> 1. How to suppress warning for "optional" token in lexer?

In 2.7 you're probably out of luck with respect to that. I by far gave 
up on getting warning free things with antlr. I don't like turning 
warnings off anyway, in case I foul up something lateron and it gets 
eaten by the wrong warning surpressor. Warnings in a grammar are seldom 
completely local. And turning the warning off locally may also eat a 
more global warning if that makes sense ;)

> 2. Text of EOF token
> 
> When ANTLR (or generated parser) reports about unexpected end of file,
> error message looks like: 
> 
> a.g:2:1: expecting ID, found 'null'
> 
> I prefer to see something more informative instead of 'null'.
> I've found workaround for that,
> but propose to change default behaviour in future versions.

Is this parser or lexer? I'm kindoff surprised at this at least the null 
doesn't ring a bell my parser/lexers usually say EOF. It might be 
something triggered by a specific construct rule though.

> 3. Multiple error messages about unexpected EOF in parser.
> 
> When EOF is found in some deep parser rule, ANTLR generates syntax error messages
> for each exception handler (rule) on stack. I propose to process this case
> separately and, for example, suppress all error messages after the first one
> when EOF is reached.

This again does not really ring a direct bell with me. But there's many 
ways to have error handlers and such.. A custom errorhandler that does 
something specific for an EOF could be a first workaround.

> 4. Error handling - extend default error handler
> 
> When I specify my own error handler, ANTLR doesn't generate default one.
> But what if I process additional exception types and want use default handler
> for RecognitionException? I propose that 
> options { defaultErrorHandler=true; }
> turn on default error handler generation in this case.

How about the ordering of the default one and your specific ones? 
Depending on the place and your custom exception hierarchy the one might 
eat the exception for the other.

> 5. How to use follow set in user defined exception handlers?

$FOLLOW
$FIRST
$FOLLOW(rulename)
$FIRST(rulename)

Expand to the bitsets names you can make a copy and modify the bitset in 
the error handler I do sometimes to kick a specific token out to tweak 
the consumeUntil to be a bit more sensible.

Cheers,

Ric