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

chore: Upgrade to ron to 0.9 #476

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

polarathene
Copy link
Collaborator

@polarathene polarathene commented Oct 17, 2023

Changes


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.

- 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` implements 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_).
- Clarified that the option value variant dereferences a boxed ron value.

Signed-off-by: Brennan Kinney <5098581+polarathene@users.noreply.github.com>
@polarathene
Copy link
Collaborator Author

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?)

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.

3 participants