I was looking at screen shots of antlrworks and it showed a lot of neat debugging tools that would graph ambiguities and debug through the parsing steps graphically. This is exactly what I'd like to be able to do in antlrworks2. Are there similar hidden gems in antlrworks2?
The decision tree graph that highlight ambiguities would be amazing, but how do I get the generated ATN graph Mr. Harwell show's on the issue tracker (https://f.cloud.github.com/assets/1408396/398668/e19e283c-a85c-11e2-8dac-0d29979906d9.png)
I have been able to remote debug into the test rig but stepping through it has not been very beneficial at trying to track down ambiguities. The output about ambiguities isn't helpful either. Even though it shows d=<N> and then the alternatives I haven't been able to figure out how to map <N> to rules in larger parser and it appears that the ambiguity numbers don't always match up to same alternatives depicted in the grammar. My guess is that they are matching the unrolled recursive grammar which makes the diagnostic output unhelpful.
One thing I would like to see the test rig do is something similar to --trace. I'd like to see the trace entering and exiting EVERY parser rule so I can track decision branch flow to better see when the grammar isn't working how I expect it to. I think that would have helped out a bunch when I spent the last couple of days tracking down an issue with the grammar that turned out to be an antlr decision bug. The only way I found out it was a bug was by updating antlr4 to the latest git commit and now it all magically works.
Another thing I would like to see is the ability to use the lexer debugger in antlrworks2 against the output from test rig's tokens option. The language I'm generating unfortunately requires several predicates in the lexer so the tokens shown with the lexer debugger does not match the tokes generated by the actual lexer in production.
Anyway, I can't wait to see the next revision of antlrworks2 and more information on how to effectively debug antlr4 grammars!
Thanks,
James
--
You received this message because you are subscribed to the Google Groups "antlr-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to antlr-discussi...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Note that setTrace uses addParseListener, and is therefore subject to the limitations described in that method. Here is a copy of the latest documentation describing the limitations of a parse listener.
/**
* Registers {@code listener} to receive events during the parsing process.
* <p/>
* To support output-preserving grammar transformations (including but not
* limited to left-recursion removal, automated left-factoring, and
* optimized code generation), calls to listener methods during the parse
* may differ substantially from calls made by
* {@link ParseTreeWalker#DEFAULT} used after the parse is complete. In
* particular, rule entry and exit events may occur in a different order
* during the parse than after the parser. In addition, calls to certain
* rule entry methods may be omitted.
* <p/>
* With the following specific exceptions, calls to listener events are
* <em>deterministic</em>, i.e. for identical input the calls to listener
* methods will be the same.
*
* <ul>
* <li>Alterations to the grammar used to generate code may change the
* behavior of the listener calls.</li>
* <li>Alterations to the command line options passed to ANTLR 4 when
* generating the parser may change the behavior of the listener calls.</li>
* <li>Changing the version of the ANTLR Tool used to generate the parser
* may change the behavior of the listener calls.</li>
* </ul>
*
* @param listener the listener to add
*
* @throws NullPointerException if {@code} listener is {@code null}
*/
public void addParseListener(@NotNull ParseTreeListener listener) {
Thank you,
--
Sam Harwell
Owner, Lead Developer