tunnelvisionlabs/antlr4

Unexpected parsing result in left recursive rule

daniellansun opened this issue · 7 comments

daniellansun commented

Hi @sharwell ,

expression
    :  { SemanticPredicates.isTypeCast(_input) }? 
       castParExpression expression                                                        #castExprAlt

( the relevant workaround: https://github.com/danielsun1106/groovy-parser/blob/bbf0d3abaa2cf8cfdde3a8a3588bf39df2989083/src/main/antlr/GroovyParser.g4#L779-L788 )

If the above semantic predicate fails, antlr4 will not choose other alternatives of expression, so we have to extract castExpression rule.
In addition, even if we can workaround the semantic predicate issue, we found the priority of expression is not correct either, e.g.
(Integer) m() instanceof Integer should be parsed as ((Integer) m()) instanceof Integer, but is parsed as (Integer) (m() instanceof Integer) currently. As you can see, we put the castExpression at the first place so we thought it should have higher priority than instanceof expression.

Please have a look into the issue. Thanks in advance.

Cheers,
Daniel.Sun

sharwell commented

Thanks for creating that branch 😄

  • 😄1
daniellansun commented

As the next major version of Apache Groovy is based on your highly optimized fork, we wish you could set aside more time on the development of antlr4 😉

sharwell commented

@danielsun1106 I sent you a bunch of things on Gitter 😄

  • 😄1
sharwell commented

@danielsun1106 Please let me know if you are able to create a small standalone grammar to reproduce this issue and/or test the snapshot release that fixes support for baseContext (which should allow this rule to be written without a predicate). For now I'm going to move this to my backlog.

daniellansun commented

@sharwell Thanks for tracking the issue. I am spending my vacation and will have some spare time to continue focusing on verifying the SNAPSHOT version 😉

daniellansun commented

As 4.7.3 works well, I will close the issue.