Ok, the code is actually correct. If you look at the code comment for
rewind:
/** Rewind to the input position of the last marker.
* Used currently only after a cyclic DFA and just
* before starting a sem/syn predicate to get the
* input position back to the start of the decision.
* Do not "pop" the marker off the state. mark(i)
* and rewind(i) should balance still. It is
* like invoking rewind(last marker) but it should not "pop"
* the marker off. It's like seek(last marker's input position).
*/
void rewind();
it should not release the marker. If they're still at least one
marker, remove will not clear the buffer:
public T remove() {
T o = get(0);
p++;
// have we hit end of buffer and not backtracking?
if ( p == data.size() && markDepth==0 ) {
// if so, it's an opportunity to start filling at index 0
again
clear(); // size goes to 0, but retains memory
}
return o;
}
rewind() just rewinds the last marker but doesn't release it. It
shouldn't flush. I added a comment to make it more clear in my
LookaheadStream
public void rewind() {
rewind(lastMarker); // rewind but do not release marker
}
Ter
On Mar 3, 2009, at 4:06 PM, Sam Harwell wrote:
> Taken from Java.stg, we end up with a mismatched mark/rewind, which
> causes the temporary stream buffer (FastQueue) to flush during a
> predict operation that encounters predicates.
>
> /** A state in a cyclic DFA; it's a special state and part of a big
> switch on
> * state.
> */
> cyclicDFAState
> (decisionNumber,stateNumber,edges,needErrorClause,semPredState) ::= <<
> int LA<decisionNumber>_<stateNumber> = input.LA(1);<\n>
> <if(semPredState)> <! get next lookahead symbol to test edges, then
> rewind !>
> int index<decisionNumber>_<stateNumber> = input.index();
> input.rewind();<\n>
> <endif>
> s = -1;
> <edges; separator="\nelse ">
> <if(semPredState)> <! return input cursor to state before we
> rewound !>
> input.seek(index<decisionNumber>_<stateNumber>);<\n>
> <endif>
> if ( s>=0 ) return s;
> break;
> >>
>
> For now I noticed it “works” to simply add a call input.mark() right
> after the call to input.rewind(), but I don’t think that’s the
> proper solution.
>
> Sam
> _______________________________________________
> antlr-dev mailing list
> [email protected]
> http://www.antlr.org/mailman/listinfo/antlr-dev
_______________________________________________
antlr-dev mailing list
[email protected]
http://www.antlr.org/mailman/listinfo/antlr-dev
