[antlr-interest] Possible bug in code generated for Lexer?

Jim Idle jimi at temporal-wave.com
Wed Jun 20 08:10:22 PDT 2007


It does look like a bug in that the codegen template has the reference
hard coded, but maybe Ter had some cunning plan that is documented in a
wiki article or something. Ter needs to take a look I think and give
some comment (which may be 'buy the book' ;-).

 

However, your stated need seems to be a bit overkill as storing a
reference to the filename is not really required. The token has a
reference to the input stream already (.input), from which you should be
able to derive the filename in any error messages and so on without
changing the token interface.

 

Jim

 

From: antlr-interest-bounces at antlr.org
[mailto:antlr-interest-bounces at antlr.org] On Behalf Of Tim Clark
Sent: Wednesday, June 20, 2007 7:45 AM
To: antlr-interest
Subject: [antlr-interest] Possible bug in code generated for Lexer?

 

Hi

I reported this before and got no response from anyone. Hopefully this
time I'll be more lucky.

I have the option:
     TokenLabelType=SL3Token

in my parser, where SL3Token extends CommonToken. [I want to save the
name of included file in the tokens.] 

This lexer rule:

INCLUDE
    :    'include' (WS)? f=STRING ;

generates code like this:

  public final void mINCLUDE() throws RecognitionException {
        try {
            int _type = INCLUDE; 
            SL3Token f=null;
     ..... stuff ......
            f = new CommonToken(input, Token.INVALID_TOKEN_TYPE,
Token.DEFAULT_CHANNEL, fStart190, getCharIndex()-1);
..... more stuff .....
}

which unfortunately is a Java error since it's trying to assign a
CommonToken to an SL3Token. I think this must be an Antlr  bug. 

Regards





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20070620/51e70d70/attachment.html 


More information about the antlr-interest mailing list