fix: resolve oneof enum name collisions with nested types

[th0114nd]

Summary

Fixes #31.

When a protobuf message has a nested type (message or enum) whose PascalCase name collides with a oneof enum's PascalCase name, the codegen now suffixes the oneof enum with Oneof instead of returning a hard NestedTypeOneofConflict error.

• oneof region_codes + message RegionCodes → generates RegionCodesOneof enum
• oneof my_field + message MyField → generates MyFieldOneof enum
• Non-colliding names are unchanged
• If the suffixed name also collides with a nested type (pathological case), an OneofSuffixConflict error is returned

The suffix is applied consistently across all code paths: struct field types, enum definitions, view enums (MyFieldOneofView), binary encode/decode, text format, and JSON serde.

Changes

• oneof.rs: Added reserved_names_for_msg() helper and modified oneof_enum_ident() to accept a reserved name set and suffix with Oneof on collision
• message.rs: Builds reserved set, threads through oneof_enum_ident call sites
• impl_message.rs, impl_text.rs, view.rs: Thread msg parameter to compute reserved names at each oneof_enum_ident call site
• lib.rs: Removed check_nested_type_oneof_conflicts() upfront validation and NestedTypeOneofConflict error variant; added OneofSuffixConflict for pathological double-collision case
• tests/naming.rs: Converted error-asserting test to success-asserting with Oneof suffix check; added tests for nested enum collision, view suffix propagation, and double-collision error

Test plan

• Existing test_nested_type_oneof_conflict_resolved_with_suffix — nested message + oneof collision generates MyFieldOneof
• New test_nested_enum_oneof_conflict_resolved_with_suffix — nested enum + oneof collision (gh#31 example) generates RegionCodesOneof
• New test_nested_type_oneof_conflict_view_uses_suffix — view enum uses MyFieldOneofView
• New test_oneof_suffix_double_collision_errors — pathological case errors cleanly
• Existing non-collision tests still pass
• Full workspace cargo test passes (233 tests)
• cargo clippy --workspace -- -D warnings clean
• No WKT regeneration needed (no collisions in well-known types)

Made with Cursor

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[th0114nd]

I have read the CLA Document and I hereby sign the CLA

[th0114nd]

Added a follow-up commit addressing a code review finding: sequential oneof ident allocation to prevent sibling oneofs from claiming the same suffixed name.

Example: nested message MyField, oneof my_field → MyFieldOneof, second oneof my_field_oneof → would also produce MyFieldOneof. The fix introduces resolve_oneof_idents() which processes oneofs in declaration order, growing the reserved set after each allocation. All call sites now look up pre-computed idents from a HashMap<usize, Ident> instead of independently calling oneof_enum_ident.

[iainmcgin]

Thanks for the PR! I took the branch forward with a few changes before review. Summary of what's changed relative to your initial version:

Naming rule — switched from conflict-driven to uniform suffix

Your PR kept the oneof enum at its PascalCase form (MyField) in the no-conflict case and appended Oneof only when a sibling nested type forced it. I changed this to apply the Oneof suffix unconditionally: oneof my_field always emits pub enum MyFieldOneof (and pub enum MyFieldOneofView<'a> when views are on), regardless of sibling names.

The reason: the prior rule made the generated type name a silent function of which sibling types exist in the same message. Adding a nested message whose Rust name happens to match an existing oneof would rename the enum from MyField to MyFieldOneof and break every downstream caller with no codegen-level signal. Uniform suffixing makes the Rust name derivable from the .proto alone and makes the addition of nested types non-breaking. It costs a one-time source break for existing buffa users, which is worth taking before 1.0. A follow-up will likely move all name-derived generated types (oneofs, views, etc.) into dedicated sub-modules so the Oneof suffix goes away entirely — this PR is the intermediate step.

Error variant renamed

CodeGenError::NestedTypeOneofConflict → CodeGenError::OneofNameConflict { scope, oneof_name, attempted }. The scope field (parent message FQN) was missing from the original error; it's important for diagnosing conflicts in large descriptor sets. The variant now fires only when {Name}Oneof itself already names another item in the enclosing scope, at which point the user must rename in the .proto.

View-side collision fix

I caught a latent bug where the derived {Name}OneofView could collide with a sibling nested message's view struct. Reserved-name tracking now spans both the owned and view namespaces, and sibling oneofs grow each other's reserved sets so two oneofs in the same message can't end up claiming the same view enum name.

Generated-code regeneration + hand-written updates

Because this is a workspace-breaking rename, I regenerated buffa-types/src/generated/ and buffa-descriptor/src/generated/ (via task gen-wkt-types / task gen-bootstrap-types) and updated the hand-written call sites in buffa-types/src/value_ext.rs, the collisions::status tests, and the envelope tests to use the new names (Value::KindOneof, Status::StatusOneof, envelope::ContentOneof, etc.).

Docs

Rewrote the "Oneofs" section in docs/guide.md to describe the uniform naming rule.

Tests

• Renamed tests to match the new semantics (removed "conflict_resolved_with_suffix" framing since there's no longer a conflict-driven path).
• Added test_sibling_oneof_view_names_do_not_collide covering the cross-oneof view-name collision case.
• Added test_oneof_suffix_conflict_error_includes_scope to lock in the new error shape.
• Existing coverage for sequential allocation and double-collision errors preserved.