[antlr-interest] [C target] [3.1.1] Deriving imaginary nodes from real tokens

[Jim Idle]

On Fri, 2008-12-12 at 09:40 +0100, Sven Van Echelpoel wrote:

> [...]
> > > 
> > I'll take a look - does that snippet of code above reproduce it? What
> > options {} have you got set etc? If you have the time, then a small,
> > but complete, grammar would be helpful :-)
> > 
> It does. I have attached the grammar and and the resulting C file. With
> 1 argument, this is the code that is generated from that template:
> 
> #if 1 == 2
> (pANTLR3_BASE_TREE)ADAPTOR->createTypeTokenText(ADAPTOR, BAR,
> TOKTEXT(b))
> #else        	
> (pANTLR3_BASE_TREE)ADAPTOR->createTypeText(ADAPTOR, BAR,
> (pANTLR3_UINT8)b)
> #endif
> 
> While, on the other hand, with 2 arguments you get this:
> 
> #if 2 == 2
> (pANTLR3_BASE_TREE)ADAPTOR->createTypeTokenText(ADAPTOR, BAR, TOKTEXT(b,
> ""))
> #else
> (pANTLR3_BASE_TREE)ADAPTOR->createTypeText(ADAPTOR, BAR,
> (pANTLR3_UINT8)b, "")
> #endif
> 
> With one argument, you can see that a node is created from the text,
> while with 2 arguments the token along with the text is passed.
> 
> Thanks for looking into this, even though there is an easy workaround.



Ah yes -  I should have documented this better (and will), but there is
no workaround in the templates for this because the code generator
relies on overloaded functions in Java/C# etc. With one argument, I have
to assume the one type, and with 2 arguments, the other. Unless we
change how this is generated in templates (I think I raised this issue
before but forget), it will have to remain this way I am afraid.

Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20081212/1e69b51f/attachment.html