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

Handle errors returned by cmark_resume_with_options() #244

Merged
merged 5 commits into from
Jan 17, 2025

Conversation

cip999
Copy link
Contributor

@cip999 cip999 commented Dec 16, 2024

Here's the follow-up to Byron/pulldown-cmark-to-cmark#91!

PR Byron/pulldown-cmark-to-cmark#93 in the
cmark_pulldown_to_cmark crate added structure to the error type returned by
`cmark_resume_with_options()`. It also  made it return an error when the
input is an inconsistent stream of `Event`s.

Now, instead of panicking, we can propagate the error to the caller and
report a more specific error.
@cip999
Copy link
Contributor Author

cip999 commented Dec 16, 2024

Oh, I see now that the version bump was already done in #242 by @kdarkhan. I'll keep my first commit here (for now) since I find the workaround slightly cleaner than what the merged PR does — then I can rebase either way, depending on what you prefer.

newlines_before_start: 0,
padding: Vec::new(),
..state
let simplified_state = state.map(|mut state| {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does indeed look cleaner. I did not think that I could work on the state as a mutable within map even though the option itself is immutable. This part looks good to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good, I kept it! :)

translated
// Translation should always succeed.
let translated_events =
translate_events(&events, catalog).expect("Fatal: failed to translate events");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this Fatal: prefix needed here? It seems to be inconsistent with the rest of expect() failures we have in this codebase.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right I can't see it anywhere else, removed it. And panic is already fatal anyway...

@@ -462,7 +462,7 @@ fn heuristic_codeblock<'a>(
_ => true,
};

if is_translate {
Ok(if is_translate {
Copy link
Collaborator

@kdarkhan kdarkhan Dec 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: wrapping the expression in Ok looks to me a bit harder to read but maybe this is the way to do it in rust (haven't done much rust yet). Will this be more readable if you store the result into two variables - events and ctx, then at the end of the function do Ok((events, ctx))?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, done! I've written even less rust, so I have no idea what the proper "rust style" would be (or if it there's a preferred way in the first place). But your suggestion looks more readable.

@kdarkhan
Copy link
Collaborator

Oh, I see now that the version bump was already done in #242 by @kdarkhan. I'll keep my first commit here (for now) since I find the workaround slightly cleaner than what the merged PR does — then I can rebase either way, depending on what you prefer.

Thanks for handling this, @cip999! Please rebase this on top of latest changes. Would be good if @mgeisler could take a look as well since he has some context on this issue.

@cip999
Copy link
Contributor Author

cip999 commented Dec 18, 2024

Oh, I see now that the version bump was already done in #242 by @kdarkhan. I'll keep my first commit here (for now) since I find the workaround slightly cleaner than what the merged PR does — then I can rebase either way, depending on what you prefer.

Thanks for handling this, @cip999! Please rebase this on top of latest changes. Would be good if @mgeisler could take a look as well since he has some context on this issue.

Thanks for reviewing! Yes that's a good idea, and it can wait, there's no rush to merge this PR right now. 🙂

@codecov-commenter
Copy link

codecov-commenter commented Dec 19, 2024

Codecov Report

Attention: Patch coverage is 76.37795% with 30 lines in your changes missing coverage. Please review.

Project coverage is 84.74%. Comparing base (a3bb63f) to head (96a88ba).
Report is 2 commits behind head on main.

Files with missing lines Patch % Lines
i18n-helpers/src/lib.rs 65.30% 3 Missing and 14 partials ⚠️
i18n-helpers/src/gettext.rs 91.52% 4 Missing and 1 partial ⚠️
i18n-helpers/src/xgettext.rs 63.63% 0 Missing and 4 partials ⚠️
i18n-helpers/src/normalize.rs 57.14% 1 Missing and 2 partials ⚠️
i18n-helpers/src/preprocessors/gettext.rs 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #244      +/-   ##
==========================================
- Coverage   84.87%   84.74%   -0.13%     
==========================================
  Files          15       15              
  Lines        3366     3377      +11     
  Branches     3366     3377      +11     
==========================================
+ Hits         2857     2862       +5     
+ Misses        422      413       -9     
- Partials       87      102      +15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Co-authored-by: Martin Geisler <[email protected]>
@kdarkhan kdarkhan merged commit 886f15e into google:main Jan 17, 2025
7 checks passed
@kdarkhan
Copy link
Collaborator

Thanks for contribution, @cip999!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants