-
-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange results with stack and non-matching alternative #394
Comments
Btw. I got it working with a better grammar that uses the stack in a saner way:
However, it still bothers me whether it's a bug; seems like the state of the stack is not the same when trying the next alternative after a failed one. |
Okay, tried to instrument the generated parsing code a bit. (Btw. if there is a better way to debug than doing
I'm getting a trace like this. Indeed, the return value of
|
Allright, got a bit further. It seems that the problem is with |
395: Clearing checkpoints in error handler on successful parse r=dragostis a=golddranks * When `restore_on_err` is called, a checkpoint is added. * When parsing fails inside the call, the checkpoint is resumed. Specifically, stack is resumed to the state it was before entering `restore_on_err`. * However, when parsing inside `restore_on_err` succeeds, at the moment, the checkpoint is not cleared on the exit. * This leads to bugs where after returning from `restore_on_err`, another error is encountered, but the checkpoint that was set in `restore_on_err` is incorrectly resumed; this causes the stack to become in inconsistent state. * Fixed the bug by adding a function for clearing checkpoints and calling it on the successful path of `restore_on_err`. * Resolves #394 * Added test for this case. However, the testing infrastructure isn't quite clear for me, so it might be that the test would be better expressed somewhere else, in some other way. Please advise on this. Co-authored-by: Pyry Kontio <[email protected]>
I'm getting strange results with the following grammar:
With test code
'' it's a test ''
and matching againstexp
, I'm expecting it to find a match, but it doesn't. Instead, with'' it's a test '''
(unbalanced single quotes), it does find a match.When I test directly against
raw_string
, it finds a match. It seems, from the behaviour, thatexp
, failing to match the first alternative, messes up the state of the stack (one-off error?) when it starts to match the next one.It might, of course, also be that I'm misunderstanding something about how the stack works, but my general understanding is that once one alternative fails to match, it shouldn't have an effect to matching the next one...?
I haven't looked in the generated code or runtime yet; just gonna start investigating now, but figured that I'd make an issue first in case there's a quick gotcha I haven't taken into account.
The text was updated successfully, but these errors were encountered: