Skip to content

Add support for lossy format strings #1693

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

Merged
merged 4 commits into from
Apr 11, 2025
Merged

Conversation

Qelxiros
Copy link
Contributor

@Qelxiros Qelxiros commented Apr 9, 2025

closes #1692

@djc You described a parse_lossy function, but I ended up writing a new_lossy function. If you think it's better to set lossy at parse time, I'm happy to change it. However, it seems better to be able to set it for the Iterator directly.

Copy link

codecov bot commented Apr 9, 2025

Codecov Report

Attention: Patch coverage is 73.91304% with 24 lines in your changes missing coverage. Please review.

Project coverage is 90.61%. Comparing base (2c95b0a) to head (80a6532).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
src/format/strftime.rs 73.91% 24 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1693      +/-   ##
==========================================
- Coverage   90.67%   90.61%   -0.07%     
==========================================
  Files          38       38              
  Lines       16874    16945      +71     
==========================================
+ Hits        15301    15354      +53     
- Misses       1573     1591      +18     

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Comment on lines 503 to 527
macro_rules! error {
() => {
if self.lossy { Item::Literal(&original[..error_len]) } else { Item::Error }
};
($ch:expr, _) => {
if self.lossy {
error_len -= $ch.len_utf8();
remainder = &original[error_len..];
}
};
($ch:expr) => {{
error!($ch, _);
error!()
}};
}

macro_rules! return_error {
() => {
return Some((remainder, error!()))
};
($ch:expr) => {
error!($ch, _);
return_error!();
};
}
Copy link
Member

Choose a reason for hiding this comment

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

Sorry, I don't want all this macro mess here -- there's probably too much already. Can you figure out a better way?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The most recent commit should be good. The coverage dropped because uncovered paths that used to be one line are now several.

Copy link
Member

@djc djc left a comment

Choose a reason for hiding this comment

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

That's much better, thanks!

Wondering if lossy is the best name for this... maybe lenient or copy_invalid? Any thoughts/suggestions?

@Qelxiros
Copy link
Contributor Author

I agree that lossy isn't a great name, and lenient has parity with something like Java's Calendar.setLenient, so that seems like the best option. Let me know if you need anything else.

@djc
Copy link
Member

djc commented Apr 11, 2025

I don't think lenient formatting is important enough to earn API exposure on every type, please confine it to the format module.

@Qelxiros
Copy link
Contributor Author

Fixed.

@djc djc merged commit e2bd1d1 into chronotope:main Apr 11, 2025
34 of 35 checks passed
@Qelxiros Qelxiros deleted the strftimeitems_lossy branch April 11, 2025 07:17
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.

Feature Request: Add non-panicking infallible format functions
2 participants