[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