Add tests for dynamic width specifiers exceeding u16::MAX

[lopopolo]

Rust PR rust-lang/rust#136932 (part of rust-lang/rust#99012) limited format string width and precision to 16 bits, causing panics when dynamic padding exceeds u16::MAX.

These tests validate handling excessively large widths discovered via fuzzing in artichoke/strftime-ruby. They ensure correct, panic-free behavior consistent with CRuby's Time#strftime.

Additionally add tests for width specifiers which exceed INT_MAX to ensure they return the formatting string verbatim, which were among the cases discussed in the upstream PR.

This does not yet fix the panics when using padding widths > u16::MAX. Would love ideas on the best approach to take for that.

See:

• Upstream report: Reduce formatting width and precision to 16 bits rust-lang/rust#136932 (comment)
• Proposed fix: Reduce formatting width and precision to 16 bits rust-lang/rust#136932 (comment)

[lopopolo]

the code coverage job is panicking because it uses nightly which has the new, panicking core::fmt::Argument::from_usize

[x-hgg-x]

There are 2 cases to solve when we have a width between u16::MAX and INTMAX:

• For left padding, we can format with a width of u16::MAX then append the difference.
• For right padding, we need to store the formatting result without a width in a temporary buffer, calculate and write the padding then write the formatted value.

I will try to make a PR implementing this.

[m-ou-se]

Does this help? m-ou-se@width

(Just posted that on rust-lang/rust#136932 (comment))

[x-hgg-x]

Does this help? m-ou-se@width

(Just posted that on rust-lang/rust#136932 (comment))

Yes, this is a good base.

[x-hgg-x]

Published #175 based on this commit.

[lopopolo]

Does this help? m-ou-se@width

(Just posted that on rust-lang/rust#136932 (comment))

thanks for the support @m-ou-se! and thanks so much for driving the perf improvements on the format machinery, the tracking issue is super chunky.

[lopopolo]

@x-hgg-x just did a slight amendment to add @m-ou-se as a co-authored-by on the commit from #175.

If this looks good to you, I'll prep and publish a release.

[x-hgg-x]

There is still a compilation failure when running cargo +1.76 test --no-default-features.

[lopopolo]

There is still a compilation failure when running cargo +1.76 test --no-default-features.

fixed in 0be636c by bumping MSRV

[lopopolo]

On branch trunk:
coveragePercent = 100.0
linesCovered = 1784
linesMissed = 0
linesTotal = 1784

On PR artichoke/strftime-ruby#172:
coveragePercent = 99.79
linesCovered = 1907
linesMissed = 4
linesTotal = 1911

code coverage job is failing because some of the more detailed assert!s that got added are formatted so the macro spans multiple lines. codecov doesn't like that and treats the assert messages as uncovered. Seems fine.