Mechanism to control backtracking?

[xldenis]

Is there any way to control backtracking in rust-peg? Some parsers start with prefixes that disambiguate the following tokens, and I'd like to force rust-peg to commit: if the parser fails, don't attempt another parse, but fail upwards. Since it currently fallback to trying another parser, this can cause parse errors to be misleading.

As a concrete issue, I have the following failing code:

  if (this.next != null) {
    addother(this.next, i)
  } else { }

the error initially tells me to look at the start of the else block, but removing the contents of the first branch allows the parser to pass successfully. I feel like I would have gotten a better error if the first { had committed the parser to successfully parsing a "block" .

I've fixed this problem since then, but for reference here was the prior error message:

cargo run test/0113.vpr
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/parser test/0113.vpr`
test/0113.vpr
peg:  error at 35:3: expected one of ",", ":="
Failed to parse 1 / 1 files

where 35:3 points to exactly the start of the else block.

[kevinmehall]

It would be helpful to see your grammar code, because it's not clear to me what the parse error in the first block is, and given that error, what part of the rule is accepting the } else { to reach the second block as error position. What is the error position and expected set you are hoping to see?

Your description sounds like the cut operator available in some other PEG implementations but this is usually presented as a performance optimization and I am not sure what effect it is supposed to have on the error heuristic.

[xldenis]

It would be helpful to see your grammar code, because it's not clear to me what the parse error in the first block is, and given that error, what part of the rule is accepting the } else { to reach the second block as error position. What is the error position and expected set you are hoping to see?

Unfortunately I noticed this in the middle of a bunch of grammar fixing, so I don't have the broken grammar on hand any longer. I'll try to break it back to how it was before though :)

Your description sounds like the cut operator available in some other PEG implementations but this is usually presented as a performance optimization and I am not sure what effect it is supposed to have on the error heuristic.

That's exactly what I was thinking of, and the performance benefits weren't unnoticed by me as well :)