[antlr-interest] [C target] [3.1.1] Deriving imaginary nodes from real tokens
Jim Idle
jimi at temporal-wave.com
Fri Dec 12 15:11:23 PST 2008
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
More information about the antlr-interest
mailing list