Replies: 3 comments
-
Currently the only ways to make a rust-peg parser return an error are the Some other PEG implementations have a construct that bails out of parsing entirely, without trying any alternatives. Is that what you're looking for here? This recently came up on #308. It looks like the rule you have is doing some kind of error recovery. There's some discussion of that in #276. I think the best approach to an IDE/LSP ready parser may be to make the parser never fail, but include error nodes in the resulting output. I recently tried that and found that it worked, but it's tricky to avoid ambiguity between the normal rules and those added for error recovery. |
Beta Was this translation helpful? Give feedback.
-
I don't think that's applicable here. Normally if the parser succeeds without consuming all the input, it generates a failure expecting |
Beta Was this translation helpful? Give feedback.
-
Indeed that's the direction I was heading by implementing cPython's Unrelated I am at a pause point in my project and started profiling/optimizing what I've written so far. Rust-peg is remarkably fast and efficient. |
Beta Was this translation helpful? Give feedback.
-
I mostly have cPython's PEG grammar implemented but I am currently trying to implement their
invalid_
rules here https://github.com/python/cpython/blob/main/Grammar/python.gram#L1077I tried
And that seems pretty close as I get
Note, I have a bug in my tokenizer currently where the line # is wrong for EndMarker but ideally I would like to halt the parser at the syntax error without using
panic!()
I saw theno_eof
directive mentioned in various pull and issue discussions but I wasn't sure if that would work or how it would work in my situation.My grammar file is here https://github.com/devdave/rython4/blob/master/src/parser/grammar.rs#L122 and it works well for syntactically correct code.
Any help/pointers is greatly appreciated!
Beta Was this translation helpful? Give feedback.
All reactions