Action code blocks and side effects

[knewt]

I see that the rust action code blocks are required to be free of side effects, as they can be called multiple times. I was wondering what the specific situations are that can cause that to happen?

Also, the code block will only ever get called if the particular rule/choice that it's associated with was successful, right? If it does get re-run, will any previous result have been droped before that point?

[kevinmehall]

On a parse error that exhausts all alternatives, rust-peg will restart the parse in an error tracing mode to collect the expected set to report in the error message (this is not enabled in the initial parse because it's slow, and not needed in the likely case of a successful parse). All the action code blocks before reaching the error will be re-run. If a conditional action code block returns a different Ok/Err status forcing the parser onto a different path than the first parse, the implementation may panic. Yes, the prior partial parse tree will be dropped before re-parsing.

The other case that isn't technically running it multiple times but where you should be careful of side effects is that action code can run for branches that later fail and backtrack, meaning the return values will be dropped and not be included in the final parse tree.

For example, the below will print "1" and "2" on input "ab":

rule foo()
    = ("a" { println!("1") }) "z"
    / ("a" { println!("2") }) "x"
    / "ab"

Yes, the code block can only be called if the associated sequence is successful up to the point of the code block (otherwise, it wouldn't have values for the capture variables used in the block).

[knewt]

Just realised I didn't respond, apologies. I think I could have worked with that, but I've come up with a different way of doing things that won't have to worry about this. Now - in a completely different issue - I've got to figure out how to best deal with line endings. I'm thinking I may have to just append a line ending at the end of my input string, in case the file that I've read in doesn't actually have a final line ending present

[kevinmehall]

You can also use ![_] as an idiom that only matches at EOF, so you may be able to use "\n" / ![_] or similar for "end of line or end of file".

[knewt]

Ah, doh, I'd missed that. Yeah, that should solve it for me, ta muchly. Currently have a rule nl() = quiet!{"\r\n" / "\n" / "\r"} / expected!("newline"), so I guess creating a rule eof() = quiet!{![_]} / expected!("EOF"), and then a rule nl_eof() = nl() / eof() for cases where I want to allow either. Hmm, which thinking about it will likely be most if not all of them!