Make it possible for `combine::primitives::ParseError` to be `std::error::Error` for more range types about combine HOT 3 CLOSED

Oh, I forgot a wrinkle: we want std::error::Error so that we can use https://github.com/brson/error-chain. However, error-chain doesn't support error types that contain references and lifetimes (although I can't find the issue where I learned this right now). That means it might not be enough to solve this problem for us; we might need additional support for converting range types to owned types in errors.

Maybe what I want is to require ToOwned when constructing the Info objects in errors? It looks like one type can have multiple ToOwned implementations, so this still might not be specific enough.

from combine.

That means it might not be enough to solve this problem for us; we might need additional support for converting range types to owned types in errors.

This I think is the first problem we should solve. For the errors actually created by the parser I don't see any way around the the errors having lifetimes in them. I think the best way to work around that is to make it easy to transform a ParseError with lifetimes into one without them. If ParseError were defined as a type with three parameters (ParsError<Position, Item, Range>) instead of the current which only takes Input https://docs.rs/combine/2.2.2/combine/struct.ParseError.html, then it would be possible to provide a map function.

fn map(self, f: impl FnMut(Position) -> Position2, g: impl FnMut(Item) -> Item2, h: impl FnMut(Range) -> Range2) -> ParseError<Position2, Item2, Range2>

I always wanted to this change but I have held out waiting for rust-lang/rust#21903. If that issue were fixed it should be possible to do

type ParseError<S: StreamOnce> = ParseErrorEx<S::Position, S::Item, S::Range>;

struct ParseErrorEx<P, I, R> { .. }

from combine.

Ah, interesting, that would be nice. I didn't want to generalize ParseError into having three types because it churns a lot of combine, and it churns external consumers.

Locally, I have elected to post-process ParseError<&'a [T]> into a simpler error with owned ranges. To do that, I implemented a map-like function map_err_range for ParseError, Error, and Info. I'll post a patch, since it could live in combine; but I think everything's pub, so this mapping could happen in our consuming code as well.

from combine.