Skip to content

feat: support HashSet and BTreeSet as TOML arrays#77

Open
foxcyber907 wants to merge 1 commit into
yanganto:mainfrom
foxcyber907:feat/hashset-btreeset
Open

feat: support HashSet and BTreeSet as TOML arrays#77
foxcyber907 wants to merge 1 commit into
yanganto:mainfrom
foxcyber907:feat/hashset-btreeset

Conversation

@foxcyber907
Copy link
Copy Markdown

Summary

Extends parse_type in the derive macro to recognize HashSet<T> and BTreeSet<T> alongside Vec<T>. All three serialize to TOML arrays via serde, so the existing Vec codegen path applies unchanged.

Motivation

Currently a struct field like tags: HashSet<String> fails to derive TomlExample (the type is silently ignored by parse_type, which then emits no example for the field). Users have to either rewrite the field as Vec<String> or write a manual impl TomlExample. This patch removes that friction without changing any existing behavior.

Changes

  • derive/src/lib.rs: change the Vec arm of parse_type to Vec | HashSet | BTreeSet and update the doc comment.
  • lib/src/lib.rs: add hashset_btreeset test covering required HashSet<String>, BTreeSet<usize>, and Option<HashSet<String>>, with round-trip parse verification.

Test plan

  • cargo test --workspace — all 38 tests pass (37 existing + 1 new)
  • New test verifies generated TOML round-trips through toml::from_str

Treat HashSet<T> and BTreeSet<T> identically to Vec<T> in parse_type
so that struct fields using these collection types can derive TomlExample
without manual TomlExample impls. Both serialize to TOML arrays via serde,
so the existing Vec codegen path applies unchanged.

Adds test hashset_btreeset covering required, optional, and BTreeSet forms.
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.

1 participant