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