[antlr-interest] ANTLR could not analyze...

Steve Bennett stevagewp at gmail.com
Mon Feb 18 14:53:47 PST 2008


On 2/19/08, Jim Idle <jimi at temporal-wave.com> wrote:
> I doubt it is a bug, but it is possible. Are using backtrack=true? I
> think that that will be necessary for what you are parsing, as though
> you could probably find ways around it, I am not sure you would end up
> with anything better than backtracking with memorization in this case.
> Also, give the latest snapshot a try and see if you get anything
> different, just in case.

With backtrack=true, I don't get the warnings, but the grammar also
doesn't behave quite correctly. Not sure why, but in a standard test
input, one of the rules fails. Probably fixable. I guess I've been
avoiding backtracking until now to really understand what it does...it
may be a good solution for readability though.

Can you explain why the warnings don't appear with backtrack=true?

I can't really test the snapshot (immediately) because it treats
certain warnings as errors. Eg, "The following alternatives are
unreachable: 1". In ANTLRworks that's a warning, with the snapshot
it's an error. Actually it also seems to generate the original warning
(Could not analyze...) but then ramps it up to a warning (internal
error...could not even do k=1 for decision 20).

Were these deliberate choices? What was the reasoning?

Aside: the "following alternatives are unreachable" warning/error it
gives points to the middle character of the sequence ".)*" in my
HTML_COMMENT rule:

HTML_COMMENT:
    (('<!--') => '<!--' (options {greedy=false;}: .)* ('-->' | EOF) {
$channel=HIDDEN; })
    | '<' { $type=LT; };

Why is that unreachable?

Steve


More information about the antlr-interest mailing list