label 'label' type mismatch with previous definition: TOKEN_LABEL!=RULE_LABEL

[yankee42]

I noticed that I can't write a rule like this:

ausdruck: label=ausdruck 'x' #One
        | label='foo'    #Two
        ;

It gives the following error:

label 'label' type mismatch with previous definition:
TOKEN_LABEL!=RULE_LABEL

It looks like this is because once label refers to a parser rule and once to a lexer rule. If I slightly change the rule:

ausdruck: label=ausdruck 'x' #One
        | label2='foo'    #Two
        ;

Everything works fine.
Since the labels are contained in seperate rules I think they should not interfere with each other.

(Also on stackoverflow: http://stackoverflow.com/q/15481471)

[parrt]

I believe that I did this on purpose as I generate globally visible classes
based on the label names. For the most part, having unique labels would be
the right answer I think so I guess I'll leave it. thanks.
T

On Mon, Mar 25, 2013 at 9:44 AM, yankee42 [email protected] wrote:

I noticed that I can't write a rule like this:

ausdruck: label=ausdruck 'x' #One
| label='foo' #Two
;

It gives the following error:

label 'label' type mismatch with previous definition:
TOKEN_LABEL!=RULE_LABEL

It looks like this is because once label refers to a parser rule and once
to a lexer rule. If I slightly change the rule:

ausdruck: label=ausdruck 'x' #One
| label2='foo' #Two
;

Everything works fine.
Since the labels are contained in seperate rules I think they should not
interfere with each other.

(Also on stackoverflow: http://stackoverflow.com/q/15481471)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/195
.

Dictation in use. Please excuse homophones, malapropisms, and nonsense.

[sharwell]

When the outer alts are labeled, the two labels from the example are created in different context classes with different accessors. There is no ambiguity in the grammar, actions, or generated code, so it seems this should be resolved for a future release. As a primary example, consider the following:

myRule
  : Foo+ # Label1
  | Foo  # Label2
  ;

In this example, the generated Label1Context contains a Foo() method that returns List<? extends TerminalNode>, where Label2Context contains a Foo() method that returns just TerminalNode.

I set the milestone to 4.x to indicate a future release that's TBD.

[parrt]

Don't we create Label1Context that is globally visible? what that collide
with another Label1Context from another method?
Ter

[ferhaterata]

Hi Sam,

Could you please check the same problem starts to occur again in 4.6? Because the same grammar works well in 4.5.3.

label left=expression type mismatch with previous definition: left=formula

Thanks.

[KvanTTT]

@ferhaterata this is a correct behavior. See this issue for detail: #1409

[sharwell]

@ferhaterata Can you provide a specific example of what fails? We have one unit test added in #1458 but it sounds like you may have found another scenario?

[ferhaterata]

Hi @sharwell

In the following, I provided a Grammar that ANTLR generates recognizer in 4.5.1 and 4.5.3 but fails in 4.6.1. The labels 'left' and 'right' represent two different types. Sorry for preparing a verbose grammar.

grammar Test;

module: formula* ;

formula:
      left=expression 'in'  right=expression    #in
    | left=formula    'and' right=formula       #and
    ;

expression:
      left=expression '+' right=expression      #union
    | variable                                  #var
    ;

variable: IDENTIFIER;

IDENTIFIER : [a-zA-Z];

It throws

error(75): Test.g4:2:13: label left=expression type mismatch with previous definition: left=formula
error(75): Test.g4:5:57: label right=formula type mismatch with previous definition: right=expression

In fact, this one works fine,

grammar test1;

example:
    left=integer '*' right=integer  #integerExample
  | left=string  '+' right=string   #stringExample
  ;

integer: IDENTIFIER;
string: INTEGER;

STRING: [a-zA-Z];
INTEGER: [a-zA-Z];

I assume the problem occurs once repetitions are allowed in labels.

[sharwell]

@ferhaterata Those are great examples. Can you open a new issue for this since it's a regression?

[KvanTTT]

Found out the problem: it's occures in case of left-recursion rule. Will try to fix it.

[parrt]

Added new issue: #1543