Closed daniellansun closed 5 years ago
Here is the branch to reproduce the issue: https://github.com/danielsun1106/groovy-parser/commits/GROOVY-8913
Thanks for creating that branch 😄
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 😉
@danielsun1106 I sent you a bunch of things on Gitter 😄
@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.
@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 😉
As 4.7.3 works well, I will close the issue.
Hi @sharwell ,
( 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 extractcastExpression
rule. In addition, even if we can workaround the semantic predicate issue, we found the priority ofexpression
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 thecastExpression
at the first place so we thought it should have higher priority thaninstanceof
expression.Please have a look into the issue. Thanks in advance.
Cheers, Daniel.Sun