Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Owned ParseErrors #606

Open
2 tasks done
9999years opened this issue Oct 15, 2024 · 1 comment
Open
2 tasks done

Owned ParseErrors #606

9999years opened this issue Oct 15, 2024 · 1 comment
Labels
C-enhancement Category: Raise on the bar on expectations

Comments

@9999years
Copy link
Contributor

Please complete the following tasks

winnow version

master

Describe your use case

Borrowed ParseErrors are tricky and make it difficult to propagate errors past the parsing code. If there was an owned variant of ParseError, I could easily convert an existing error into (e.g.) a miette::Report or some other owned error type without stringifying it and losing its structured information.

Describe the solution you'd like

Generally, the program which calls the parser will have the input in an owned form somewhere, e.g. from calling std::fs::read_to_string. It's not possible to call parsers with &mut String input directly, because Stream::next_token can't be implemented without reallocating the entire remaining input. Therefore, I would like to be able to replace the input field in the ParseError when an error is encountered:

let input = fs::read_to_string("my-input.txt")?;
let parsed = parser.parse(&mut input.as_str())
    .map_err(|err| err.with_input(input))?; // <- Swap out the `&str` input for `String` here.

Note that this requires the offsets to match up between the old and new inputs; if the offset needs to be adjusted, it would be very useful to have the ParseError constructor available as well.

Alternatives, if applicable

#329 suggests implementing ToOwned, but that's not easy for inner references like those ParseError contains.

Additional Context

See: #329

@9999years 9999years added the C-enhancement Category: Raise on the bar on expectations label Oct 15, 2024
@epage
Copy link
Collaborator

epage commented Oct 24, 2024

If there was an owned variant of ParseError, I could easily convert an existing error into (e.g.) a miette::Report or some other owned error type without stringifying it and losing its structured information.

I feel I'm missing something here. Why does making it owned help with working with miette?

We have an example using annotate-snippets. It does use a custom error type though that is also written for the error type to be in a public API which ParseError likely shouldn't be.

https://docs.rs/winnow/latest/winnow/_tutorial/chapter_7/index.html#error-adaptation-and-rendering

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: Raise on the bar on expectations
Projects
None yet
Development

No branches or pull requests

2 participants