_localctx not casted to correct class when using Alternative Labels

[dbolotin]

Hi,

Here is a parser rule with two different types of alternatives:

• with two numerical arguments BinaryNumberOp
• with two logical arguments BinaryLogicalOp

logicalExpression returns [ LogicalExpression val ]:
                   l = number '>' r = number { $val = lt($ctx.r.val, $ctx.l.val); }   # BinaryNumberOp
                 | l = number '>=' r = number { $val = le($ctx.r.val, $ctx.l.val); }  # BinaryNumberOp
                 | l = number '<' r = number { $val = lt($ctx.l.val, $ctx.r.val); }   # BinaryNumberOp
                 | l = number '<=' r = number { $val = le($ctx.l.val, $ctx.r.val); }  # BinaryNumberOp
                 | l = number '==' r = number { $val = eq($ctx.l.val, $ctx.r.val); }  # BinaryNumberOp
                 | l = logicalExpression '&&' r = logicalExpression { $val = and($ctx.l.val, $ctx.r.val); } # BinaryLogicalOp
                 | l = logicalExpression '||' r = logicalExpression { $val = or($ctx.l.val, $ctx.r.val); }  # BinaryLogicalOp
                 ;

Here is a fragment of code generated for one of alternatives.

setState(59); 
((BinaryNumberOpContext)_localctx).l = number();
setState(60); match(T__5);
setState(61); ((BinaryNumberOpContext)_localctx).r = number();
((BinaryNumberOpContext)_localctx).val =  lt(_localctx.r.val, _localctx.l.val); 
}

The problem is that _localctx in the lt(...) function invocation is not converted to current local context type BinaryNumberOpContext, so this code can't be compiled because base class (LogicalExpressionContext) doesn't contain .r and .l fields.

I'm not sure if it is a bug, but it seems like in this situation _localctx can be casted to current local context class without any problems.

[ericvergnaud]

Hi,

I’m not sure you can ‘reuse’ a label across alternatives.
Have you tried with a dedicated label per alternative?

Eric

Le 29 nov. 2014 à 22:12, dbolotin notifications@github.com a écrit :

Hi,

Here is a parser rule with two different types of alternatives:

with two numerical arguments BinaryNumberOp
with two logical arguments BinaryLogicalOp
logicalExpression returns [ LogicalExpression val ]:
l = number '>' r = number { $val = lt($ctx.r.val, $ctx.l.val); } # BinaryNumberOp
| l = number '>=' r = number { $val = le($ctx.r.val, $ctx.l.val); } # BinaryNumberOp
| l = number '<' r = number { $val = lt($ctx.l.val, $ctx.r.val); } # BinaryNumberOp
| l = number '<=' r = number { $val = le($ctx.l.val, $ctx.r.val); } # BinaryNumberOp
| l = number '==' r = number { $val = eq($ctx.l.val, $ctx.r.val); } # BinaryNumberOp
| l = logicalExpression '&&' r = logicalExpression { $val = and($ctx.l.val, $ctx.r.val); } # BinaryLogicalOp
| l = logicalExpression '||' r = logicalExpression { $val = or($ctx.l.val, $ctx.r.val); } # BinaryLogicalOp
;
Here is a fragment of code generated for one of alternatives.

setState(59);
((BinaryNumberOpContext)_localctx).l = number();
setState(60); match(T__5);
setState(61); ((BinaryNumberOpContext)_localctx).r = number();
((BinaryNumberOpContext)_localctx).val = lt(_localctx.r.val, _localctx.l.val);
}
The problem is that _localctx in the lt(...) function invocation is not converted to current local context type BinaryNumberOpContext, so this code can't be compiled because base class (LogicalExpressionContext) doesn't contain .r and .l fields.

I'm not sure if it is a bug, but it seems like in this situation _localctx can be casted to current local context class without any problems.

—
Reply to this email directly or view it on GitHub #767.

[dbolotin]

Not, I didn't, but there is a special note about reusing labels here:

https://theantlrguy.atlassian.net/wiki/display/ANTLR4/Parser+Rules

You can reuse the same label on multiple alternatives to indicate that the parse tree walker should trigger the same event for those alternatives. For example, here’s a variation on rule e from grammar A above:
e : e '*' e # BinaryOp
| e '+' e # BinaryOp
| INT # Int
;

And everything compiles except this cast.

[sharwell]

@ericvergnaud this came up once before in an issue (don't have the link handy), where the verdict is aliasing should be allowed as long as alternative labels are used.

[ericvergnaud]

the parser could also be confused by your variables where l and r are alternately number and logical expressions
have you tried ln/rn and ln/nn?

Le 29 nov. 2014 à 22:45, dbolotin notifications@github.com a écrit :

Not, I didn't, but there is a special note about reusing labels here:

https://theantlrguy.atlassian.net/wiki/display/ANTLR4/Parser+Rules https://theantlrguy.atlassian.net/wiki/display/ANTLR4/Parser+Rules
You can reuse the same label on multiple alternatives to indicate that the parse tree walker should trigger the same event for those alternatives. For example, here’s a variation on rule e from grammar A above:
e : e '*' e # BinaryOp
| e '+' e # BinaryOp
| INT # Int
;

And everything compiles except this cast.

—
Reply to this email directly or view it on GitHub #767 (comment).

[dbolotin]

Thanks for your suggestion. Actually, it is my current workaround for tis situation. I use two pairs of variables (nl/nr and ll/lr).
But I think it would be better if access to label-specific variables became possible. Because the type of context is defined in that code region and I don't see why not.)

[parrt]

Hi. Yep, we decided sharing alt labels was ok but I'm surprised that some but not all $ctx refs are converted. Maybe a bug. Hang on...Confirmed.

grammar T;      

a : x=number '++'  {$ctx.x.INT();}      #Pre
  | x=number '!'   {$ctx.x.INT();}      #Pre
  | '--' x=number  {$ctx.x.INT();}      #Post
  ;             

number : INT ;

INT : [0-9]+ ;  

yields

_localctx.x.INT();

It seems like it could figure out $ctx's correct type. I'll check.

[dbolotin]

Good to hear that it can help.
Thanks for fast reply!