Number of rule entries in listener while parsing does not match number while walking

[DJCordhose]

This is illustrated by this test

http://code.google.com/p/antlr4-ast-visitor-sandbox/source/browse/trunk/test/EnterAndExitEveryRuleTest.java

[sharwell]

That is correct. For some contexts created by a left-recursive rule, no call to enter occurs during the parse phase.

Listeners during the parse phase should be reserved for advanced users who fully understand the nuances of the ANTLR runtime's internals and have a specific requirement to use a listener at that time, as there are many limitations to this method. All other users and for nearly all purposes a listener should only be used with a walker (generally the ParseTreeWalker.DEFAULT) after the parsing is complete.

[sharwell]

I'm closing this issue since the behavior is known and currently by design - a separate issue could be filed if there are specific requests to change the current behavior.

[parrt]

I think i'm forced to make a ParserListener that has NO enter events for left-recursive rules, only exits. Might even remove arg from enterX(). Ollie is right. This behavior should/can be captured in the interface.

[sharwell]

Better to just make Parser.addParseListener protected. There's almost no reason to ever use a parser listener - making the method protected is just leaving the hook in place should it be necessary in some particular (and obviously advanced) application.

It'd even be better to remove this capability completely than add a new interface for what is essentially a crippled version of a feature that works perfectly well when run independently of the parse.

[parrt]

Apparently "fixing" in pull request does NOT close.

[DJCordhose]

Using a parse listener might make sense at least when you need to store information and later use it to direct parse decisions. Like when using a symbol table to decide if something is an id or function or whatever.

[sharwell]

Writing a parser which manipulates state during the parse process in ways that affect prediction (including the example of a symbol table which is used by predicates) requires a deep understanding of the way ANTLR 4 makes decisions. In particular, ANTLR 4 doesn't perform the same backtracking mechanism as ANTLR 3 and only executes a limited set of traversed predicates during the prediction process for a particular decision. Changing the interface doesn't make understanding this process any easier, but does add to the overall size of generated code and makes it very difficult for someone who does understand how to write a parser listener to share such a listener with the walk phase (java doesn't have multiple inheritance, so assuming you extend FooBaseListener you have to explicitly implement the entire FooParserListener interface on such an object).

[DJCordhose]

Talking about semantic predicates. Anyway, parse listeners are in place now and things rock :)