[antlr-interest] A lost label?
Gavin Lambert
antlr at mirality.co.nz
Sat Jan 24 17:55:27 PST 2009
At 14:45 25/01/2009, Markus Stoeger wrote:
>label returns [string name]
> : x=unsignedInt {$name = $x.text;}
> | x=identifier {$name = $x.text;}
> ;
>
>The generated code (CSharp2) for this rule is below. For some
>reason ANTLR doesn't assign the label x in the first alternative
>which results in "name" being null all the time:
The trouble is that the types of the two variables are different
(one will most likely be unsignedInt_return while the other is
identifier_return).
If you tried it with tokens instead of subrules then you'd
probably find that it works as expected, since they're the same
type then.
>case 1 : {
> unsignedInt(); // missing assignment to label x!
> name = ((x != null) ?
>input.ToString((IToken)(x.Start),(IToken)(x.Stop)) : null);
> break;
> }
>case 2 : {
> x = identifier();
> name = ((x != null) ?
>input.ToString((IToken)(x.Start),(IToken)(x.Stop)) : null);
> break;
> }
[...]
>Shouldn't it be possible to use the x label for both
assignments,
>since they are assigned in two different alternatives? The book
>(page 124) says "variables are visible to the immediately
>surrounding alternative, but not other alternatives". If I
>understand this right, each alternative has its own scope so
>reusing the variable name in another scope should be possible?
It should be (and at the grammar level it is), but as you can see
from the generated code that's not what's actually happening; the
variables are declared in the containing scope. (And that in turn
is necessary because people expect that in other situations.)
>Or maybe ANTLR could display an error while generating the
parser
>in such a case? That would be better than silently discarding
the
>assignment... :-)
Yes, that would be better.
More information about the antlr-interest
mailing list