-
-
Notifications
You must be signed in to change notification settings - Fork 183
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
Struct capture wrongly applying previous captures in a failed branch #216
Comments
@alecthomas ping about this. The generated parser will differ from the reflective parser's behavior here and I would like to make sure that the reported behavior is indeed incorrect - definitely seems so. |
Definitely a bug. I'm pretty surprised this hasn't come up before TBH. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey, while working on parser code generation and implementing lookahead error recovery, I noticed a bug. Consider this example:
I tried to make it as minimalistic as reasonable, it's quite an obscure bug that's unlikely to bother someone but I thought I'd report it anyway.
strct.Parse
will callctx.Apply
even ifs.expr.Parse
returned an error. The purpose of that is apparently providing a partial AST in case the entire parsing fails, but is has an unwanted side-effect. Any captures added toparseContext.apply
added by the branch so far will be applied, even though the error may later be caught by a disjunction or a ?/*/+ group and recovered. I think this can only happen if lookahead is at least 2, as it requires one token for that unwanted capture and a second token for thestrct
to return an error instead of nilout
.In the example above, the input is constructed to match the second disjunction alternative, but the first tokens will initially lead it into the first alternative and into the
BugFirstAlternative
struct. When attempting to matchIdent
for theValue
field, the sequence will fail and return an error, butctx.apply
will already contain a capture forBugStructCapturesInBadBranch.Bad
, which will be applied instrct.Parse
, even though the disjunction recovers it and matches the second alternative.I don't think it's super important this is fixed, but my code generation parser's behavior will differ from this, because I'm trying to take a different approach to recovering failed branches - restoring to a backup of the parsed struct when branch fails instead of delaying applying captures.
The text was updated successfully, but these errors were encountered: