Implement std::error::Error for lrpar::lex::Lexeme<T>

[pablosichert]

It would be nice if std::error::Error was implemented for lrpar::lex::Lexeme<T>.

That way, if we're in the context of a -> Result<T, Box<dyn std::error::Error>> function, we can do

let value = $1?;

instead of

let value = $1.map_err(|error| format!("{:?}", error))?;

---

In context:

Integer -> Result<i32, Box<dyn Error>>:
    "INT" {
        let value = $1.map_err(|error| format!("{:?}", error))?;
        let string = $lexer.lexeme_str(&value);
        Ok(string.parse::<i32>()?)
    }
;

$1 is of type Result<Lexeme<u32>, Lexeme<u32>> in the generated code.

[ltratt]

I'm not sure about this: I think it will confuse people, partly because Lexemes aren't very user friendly on their own. For example, my preferred idiom is:

Integer -> Result<i32, ()>:
  "INT" {
    let v = $1.map_err(|_| ())?;
    ...
  }
;

In other words, as soon as I encounter an inserted token for "something that matters", I stop evaluation (but don't bother reporting the reason why to the user, as I find that it's generally obvious from the syntax errors they will also have received).

That said, in your grammar file, could you not implement Error on Lexeme yourself, or is that forbidden because it's in another crate?

[pablosichert]

That said, in your grammar file, could you not implement Error on Lexeme yourself, or is that forbidden because it's in another crate?

Correct, that does not work, unfortunately:

error[E0117]: only traits defined in the current crate can be implemented for arbitrary types
     |
     | impl<T> std::error::Error for lrpar::lex::Lexeme<T> {}
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^---------------------
     | |                             |
     | |                             `lrpar::lex::Lexeme` is not defined in the current crate
     | impl doesn't use only types from inside the current crate

That being said, I haven't looked at the error handling / recovery of grmtools yet, because currently I get plain unrecoverable panics when I parse something unexpected. (That is, in my wasm32 build.)

I'll try to find out the cause for that, because eventually I also want to report nice errors with locations in the parser input to the user.

I don't have time for that right now, but I'll come back to this when I finished the core part of my project where I use grmtools.

[ltratt]

That being said, I haven't looked at the error handling / recovery of grmtools yet, because currently I get plain unrecoverable panics when I parse something unexpected.

That doesn't sound good! If that's a bug in grmtools, please report it back here!

[pablosichert]

After reading the Rust guidelines for publishing crates I thought of this issue again.

Due to the orphaning rules for implementing traits, they recommend eagerly implementing std::error::Error: https://rust-lang.github.io/api-guidelines/interoperability.html#c-good-err.