Add context around error

[zacps]

Currently if pest fails on a blank line it will output something like this:

 --> 8:1
  |
8 | ␍␊
  | ^---
  |
  = expected literal, single_name_part, new_indent, or continue_indent

I would like it to output a configurable number of surrounding lines a la rustc error messages.

Is it possible to configure this somewhere?

[tomtau]

If there's a line continuing after that, I think it should show it as well?

[dave-doty]

I'm running into a similar issue. I have a format for DFA transitions like this:

a,0 -> a;
a,1 -> b
b,0 -> a;
b,1 -> b;

Note the syntax error where I left off a semicolon on line 2. I want to improve the default error message in this case.

I ignore all whitespace (including newlines) between tokens.

For reference, here's the .pest grammar I use to parse such lists of transitions:

WHITESPACE = _{ " " | "\t" | NEWLINE }
COMMENT = _{ "//" ~ (!"\n" ~ ANY)* }
// state needs to be "atomic rule" (marked with @) so that 
// WHITESPACE and COMMENT don't get inserted between the * repetitions
state = @{ (ASCII_ALPHANUMERIC | "_")* }
symbol = { ASCII_ALPHANUMERIC | "_" }
semicolon = { ";" }
comma = { "," }
arrow = { "->" }
transition = { state ~ comma ~ symbol ~ arrow ~ state ~ semicolon }
file = _{ SOI ~ transition+ ~ EOI }

The error message is this (BTW, for the sake of anyone who had the same confusion I did, it took me forever to figure out that you have to call e.to_string() on the error object that comes out; if you follow the examples in the documentation (literally all of them!!) and do something like println!("{:?}", e); or panic!("{:?}", e); it prints something much less intelligible.)

Error parsing source:  --> 3:1
  |
3 | b,0 -> a;
  | ^---
  |
  = expected semicolon

It seems like it would be much more useful to print not only the line where the parser failed to find an expected token, but all of the lines in between the start token of the parent rule and the error. In this case, it was trying to parse the previous transition a,1 -> b, which should have ended in a semicolon. This corresponds to the rule transition = { state ~ comma ~ symbol ~ arrow ~ state ~ semicolon } in my grammar, which started parsing on the previous line.

It seems like a better general-purpose error message would be to take all the lines between the start of parsing transition (more generally, the parent rule, transition in this case, of the rule that failed to parse, semicolon in this case) and the error position. In this case, that would generate something like

Error parsing source:  --> 2:1-3:1
  |
2 | a,1 -> b
3 | b,0 -> a;
  | ^---
  |
  = expected semicolon

On a related note, it's awkward that I have to create subrules such as semicolon, comma, and arrow above to make the error messages more useful. If I instead write the transition rule with those "inlined" as string literals, transition = { state ~ "," ~ symbol ~ "->" ~ state ~ ";" }, one would expect the error message to say expected ;, but instead it says expected transition. Similarly if I leave off a comma, e.g., a 1 -> b, one would want the error message expected ,, but instead get expected transition. In some sense these seem like dual errors: in the case I described first, I want the see the entire context of the parent rule transition, to help the user see where all to look, even though it was technically the child rule semicolon that failed. But if I use string literals inline in a rule like transition = { state ~ "," ~ symbol ~ "->" ~ state ~ ";" }, then I would want those string literals, when they are not found, to be printed as what is expected, rather than the name of the parent rule of which they are a subrule.

[dave-doty]

Per a discussion on Discord, I think a good feature to add would be this: make two variants of "silent" rules:

1. silent = no token pairs are created. This is great for things like keywords or operators you expect to see, where as long as the keyword is there, great, the format of the content is correct, but having successfully parsed it, you don't need to be told the keyword or operator. An example would be a line of the form name = Bob, where you want to parse the = but you don't need the Parser to return a token saying where it found the =, if it parsed correctly, you know it was there and don't need to explicitly process a token pair related to it.

2. silent = no error messages are created. In fact, I don't think I would ever use this variant. I'm frankly not sure why pest ignores errors created by silent rules. An error means something went wrong; under what circumstances would you possibly not want to know what went wrong? If there is some circumstance, great, maybe have an operator for this, but I think the default behavior for silent rules should be they are silent about what was successfully parsed, but NOT silent about errors. Of course if I was expecting to see an = in name - Bob but saw - instead, I want the parser to report that error: expected =.