Javadoc
A closure operation should abort if that computation has already
been done or a computation with a conflicting context has already
been done. If proposed NFA config's state and alt are the same
there is potentially a problem. If the stack context is identical
then clearly the exact same computation is proposed. If a context
is a suffix of the other, then again the computation is in an
identical context. ?$ and ??$ are considered the same stack.
We could walk configurations linearly doing the comparison instead
of a set for exact matches but it's much slower because you can't
do a Set lookup. I use exact match as ANTLR
always detect the conflict later when checking for context suffixes...
I check for left-recursive stuff and terminate before analysis to
avoid need to do this more expensive computation.
12-31-2007: I had to use the loop again rather than simple
closureBusy.contains(proposedNFAConfiguration) lookup. The
semantic context should not be considered when determining if
a closure operation is busy. I saw a FOLLOW closure operation
spin until time out because the predicate context kept increasing
in size even though it's same boolean value. This seems faster also
because I'm not doing String.equals on the preds all the time.
05-05-2008: Hmm...well, i think it was a mistake to remove the sem
ctx check below...adding back in. Coincides with report of ANTLR
getting super slow: http://www.antlr.org:8888/browse/ANTLR-235
This could be because it doesn't properly compute then resolve
a predicate expression. Seems to fix unit test:
TestSemanticPredicates.testSemanticContextPreventsEarlyTerminationOfClosure()
Changing back to Set from List. Changed a large grammar from 8 minutes
to 11 seconds. Cool. Closing ANTLR-235.