Fwd: [antlr-interest] How to set filename in parser

Ric Klaren ric.klaren at gmail.com
Fri Jul 15 10:47:38 PDT 2005


shmuel siegel wrote:
RK>> If you set the line info correct in the lexer inputstate then tokens
RK>> should be created with the right line/column information. I don't
RK>> recall of the top of my head if CommonToken had a filename attribute.
RK>> You might have to make a custom token class and override makeToken in
RK>> the lexer to put the filename in the token as well.
RK>>
RK>> After that you may have to override reportError and friends in the
RK>> parser not sure about that though.

> Unfortunately, at least in my case it is even worse than that. If antlr 
> tries to determine the correct path with a switch failure occurs by    
>        default:
>        {
>            throw new NoViableAltException(LT(1), getFilename());
>        }
> This means that I have to either manage to set parsers filename, 
> (remember the parser never sees the #line directive) or override 
> getFilename. The latter sounds easier but then I have to find it. It is 
> saved in ParserSharedInputState as a protected member. So given your 
> answer, it looks like I will also have to save it locally in the 
> generated lexer in a way that the parser can reach it.

Hmmm that's indeed ugly. Does it work to override reportError in the 
parser and only look at the token which should have the right 
file/line/column information? Hmmm nope it won't... I'll look into it 
and look at fixing things, it will probably mean breaking backwards 
compatibility this can't be fixed without some seriuos overhauling.

I am thinking along the lines of stripping getFilename out of the parser 
and make the parser only look at the tokens for position information. 
This will mean that I have to tinker with the exception hierarchy and 
errorreporting as well.

BTW in 2.7.5 the ParserSharedInputstate has a public attribute for the 
filename. Not that it helps since there's no sure way to modify it 
consistent with the input. You can override LT to patch up the filename 
form the value stored in the token but around lookahead calculations the 
filename may be off a number of tokens thus resulting in bad reporting.

Cheers,

Ric



More information about the antlr-interest mailing list