You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to have an analog of delimited_by, which would allow to pass to the error that occurred when the closing parser worked, information about how the opening parser worked, most often span, the dumbest way to do it - inner.xxx(just(“(”“), |span| just(”“)”).map_err(|e: Error| Error::new(Expected::TupleClose(OpenBracket::new(span.clone())), e.found(), e.span()). But clearly there is a more elegant solution using the abstractions we already have.
The text was updated successfully, but these errors were encountered:
So this actually existed in 0.9: Errorhad a dedicated method for unclosed delimiters and the nested_delimiters recovery strategy would make use of it.
We could do exactly the same thing in 1.0: perhaps if this is something you'd be happy with, we can go right ahead and just implement that. My feeling is that there might be space to add something that allows for more fine-grained control over the final error though, perhaps via the labelling system, allowing the unclosed delimiter to become an extra annotation on top of the existing error (i.e: a new method that sits alongside LabelError::in_context).
I would like to have an analog of
delimited_by
, which would allow to pass to the error that occurred when the closing parser worked, information about how the opening parser worked, most often span, the dumbest way to do it -inner.xxx(just(“(”“), |span| just(”“)”).map_err(|e: Error| Error::new(Expected::TupleClose(OpenBracket::new(span.clone())), e.found(), e.span())
. But clearly there is a more elegant solution using the abstractions we already have.The text was updated successfully, but these errors were encountered: