chore: Upgrade to ron to 0.9

[polarathene]

Changes

• Clarified that the option value variant dereferences a boxed Ron value.
• Ron 0.9 refactored the Number value variant to be lossless, which requires more thorough matching.
  • 128 integer support in Ron requires feature opt-in via Cargo.toml, (as ValueKind supports an equivalent type, config-rs could opt-in).
• Ron 0.9 also introduces a new Bytes value variant to support rusty byte strings (Vec<u8>). This was to resolve a roundtrip serialization bug with base64 strings when serde deserialize_any is used (which lacks a type hint and would deserialize as a literal string to bytes, instead of base64 decoded string to bytes).

---

Note

• Ron 0.9 is not yet released, but is expected to be this month.
• This PR was prepared / tested via git dependency instead of version.

Relevance

I've had this sitting around for a while and meaning to push a PR before I forget 😅

This PR is an alternative to #472 and a sibling of #474

In particular Ron 0.9 is intended to be more robust with Value better supporting untagged enums and similar compatibility issues.

• While support is improved, there are various limitations documented in the README. A maintainer of Ron has implemented thorough fuzzing with this release which has assisted in documenting the known limitations.
• That was a concern for the proposed approach in refactor: Use a common from_value method #472 , but for config-rs is passing the Ron tests successfully regardless of Ron 0.8 or 0.9 release used.
  • No adjustment is required for 0.9 support there as deserialize_any to the untagged enum will fallback to the Nil variant when a variant is unsupported by config-rs.
  • The drawback is such changes to the Value variants of a supported format is less obvious. Although since config-rs is generic across formats, that's less important so long as functionally the format meets test expectations.

Ron 0.10 will continue to improve on the Value type, which may be relevant for config-rs.

[polarathene]

There is a YAML test with keys that are strings or numbers since the format supports that. Ron also supports this, but no equivalent test is present: #432

The YAML equivalent isn't exactly supported, config-rs just handles converting a number type to a string type for the map key. The same could be handled for Ron (and any other formats that support such), since lossless serialization / roundtripping isn't a goal of the crate, only deserializing into a config struct?

Awareness of the lossy deserialization could probably be better documented 🤷‍♂️ (similar is done for Char into String, number types too, while the new bytes variant isn't likely to be supported?)

[polarathene]

Ron finally released 0.9.0: https://github.com/ron-rs/ron/blob/master/CHANGELOG.md#090---2025-03-18

I have only updated the branch to resolve conflicts. Still lacking time to revisit my PRs here and get them in sync with any changes since that may need to be revised.

Reminder (to self) that the PR description highlights this as an alternative PR for ron 0.9.

[coveralls]

Pull Request Test Coverage Report for Build 13932004879

Details

• 5 of 11 (45.45%) changed or added relevant lines in 1 file are covered.
• 19 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-1.2%) to 64.168%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/file/format/ron.rs	5	11	45.45%

Files with Coverage Reduction	New Missed Lines	%
src/error.rs	3	80.25%
src/value.rs	16	33.01%

Totals
Change from base Build 13814737235:	-1.2%
Covered Lines:	933
Relevant Lines:	1454

---

💛 - Coveralls

[epage]

128 integer support in Ron requires feature opt-in via Cargo.toml, (as ValueKind supports an equivalent type, config-rs could opt-in).

This actually has a significant problem and we might want to wait to see how ron-rs/ron#563 gets resolved before upgrading.