Yesterday, it came to my attention that the code for generating a lookahead was incorrect for the one-or-more construct. Basically, if you have:
(Foo Bar Baz)+
the first iteration is not a choice point, so the predicate for the expansion (by default a one-token lookahead or possibly something else) is only checked after the first iteration.
This was implemented correctly (I'm pretty sure!) for parsing but when it would generate the lookahead code, it was generating code that checked the predicate on the first iteration. Or another way of looking at this is that the above should be equivalent to:
Foo Bar Baz (Foo Bar Baz)*
and should generate the same parsing AND lookahead code. Well, that is now fixed. Actually, what it was generating before would have been the lookahead corresponding to:
(Foo Bar Baz | FAIL) (FooBar Baz)*
which is not exactly the same thing, because the predicate would be checked on the first iteration. Of course, you wouldn't notice this in the cases where the predicate amounts to checking the first n tokens, but if the predicate was some other sort of condition, then you could be bitten by that.