-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect childs generation with array of element label #1163
Comments
Is |
Sorry, it's my fault. I replaced additive_expression with multiply_expression. |
I fed this to the Java runtime, and I get analogous results: grammar Agrammar;
additiveExpression : expression (op=OP expr=expression)* ;
expression : Number ;
Number : [0-9]+ ;
OP : '+' | '-' ; Looking at the code, though, I think this is the way it's intended to work. Both symbols ( public final AdditiveExpressionContext additiveExpression() throws RecognitionException {
...
try {
enterOuterAlt(_localctx, 1);
{
setState(4);
expression(); // match the first expression
setState(9);
_errHandler.sync(this);
_la = _input.LA(1); // look ahead (I'm guessing) for an operation
while (_la==OP) {
{
{
setState(5);
((AdditiveExpressionContext)_localctx).op = match(OP); // grab op
setState(6);
((AdditiveExpressionContext)_localctx).expr = expression(); // grab expr
}
}
setState(11);
_errHandler.sync(this);
_la = _input.LA(1); // fall out of loop if we don't see another OP
}
}
} so in a sense they're kind of behaving like for (Object thing: things) {
...
} I'll play with this some more and see, but that's what my gut is telling me. EDIT: Yeah, the variables are being masked from use in the listeners because there aren't any callbacks exposed for the EDIT AGAIN: If you do additiveExpression : expression (opExpression)* ;
opExpression : op=OP expr=expression ;
... you get the behavior and the listeners. |
I know about this workaround. But it's yet another rule. And this what I would like to avoid. |
I believe it is indeed the way it's supposed to work. |
There are cases in which tokens should be distinguished. In this case I want to use the value of operator in Visitor: for (int i = 1; i < context.expression().Length; i++)
{
string opValue = context.op(i - 1).GetText();
} Without op label it would be tricky. |
Have you tried the proposed alternatives? |
I did one more thing and tried to assign a label to the star expression directly: grammar Agrammar;
additiveExpression : expression star=(opExpression)* ;
opExpression : op=OP expr=expression ;
expression : Number ;
Number : [0-9]+ ;
OP : '+' | '-' ; which gives the error |
In the above grammar, if you visit opExpression you'll find that op contains the actual token text, so there is neither a bug or a need for a feature |
@ericvergnaud Just to clarify, I was speaking hypothetically. I wasn't actually suggesting a fundamental restructuring of the Antlr AST classes would be a good "feature" to add. 😄 |
intended behavior. |
I have the following rule in grammar:
But after parser generation I got the following childs in Multiply_expressionContext (C# runtime):
The text was updated successfully, but these errors were encountered: