protoc-gen-buffa: add unbox_oneof option

[fallintoplace]

What

• Add repeatable unbox_oneof=<path> support to protoc-gen-buffa.
• Normalize paths without a leading . like Config::unbox_oneof_in.
• Support unbox_oneof=. for all non-recursive message/group variants.
• Keep recursive-variant handling in the existing codegen validation.

Tests

• cargo test -p protoc-gen-buffa unbox_oneof
• task lint
• task test
• cargo test --workspace --all-features

No generated files or CI changes.

[github-actions]

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

[iainmcgin]

[claude code]

The normalization matches buffa-build::unbox_oneof_in character for character and the guide row is accurate, but the option diverges from every sibling in this parser in ways that bite:

• unbox_oneof= (empty value) silently means "unbox everything". Prepending . to an empty value yields the blanket rule. normalize_override_path exists to reject exactly this ("use '.' explicitly to match everything"), and exclude_package rejects it too; a trailing comma in opt: should not change the storage layout of every oneof in the schema. Use normalize_override_path(value.trim())? here, which also fixes the two smaller ones: the value is not trimmed (unbox_oneof= .a.B becomes ". .a.B" and matches nothing) and a trailing dot is not stripped (.my.pkg. never matches).
• Name. buffa-build spells the path form unbox_oneof_in(&[..]) and reserves unbox_oneof() for the blanket, and the plugin's other path-scoped options are all *_in=. Most rows in the guide table are foo=true, so unbox_oneof=true is the natural guess, and it parses as the path .true and silently matches nothing. unbox_oneof_in=<path> (with unbox_oneof=true as the blanket, mirroring buffa-build) avoids a breaking rename later.
• The recursion error at oneof.rs:427-432 tells a plugin user to remove the path from unbox_oneof_in or call unbox_oneof(), buffa-build vocabulary a buf.gen.yaml author never wrote; the shared_descriptor_pool rejections in main.rs show the plugin-side wording.
• docs/guide.md:925 still says message and group variants are always boxed, and the guide has no section on unboxing to point the new row at.

Tests should cover the empty, whitespace, and trailing-dot inputs. Re-review on push; on the 0.9.2 list.

[iainmcgin]

[claude code]

The rename and the normalize_override_path sharing land exactly as asked; one thing the push added undid part of it. The unbox_oneof=<path> "compatibility alias" preserved a spelling that only existed on this branch (no tag, no main commit, no release carries it), and it routed near-miss booleans — unbox_oneof=TRUE, =1, =yes — into the path parser, where they became .TRUE / .1, matched nothing, and generated boxed code with no diagnostic: the same silent-misparse case the send-back was about, one arm over. Pushed 35c55e7 rather than a third round: unbox_oneof is boolean-only through parse_bool like its siblings (with a test that TRUE/1/a path all error), the empty-path error names unbox_oneof_in instead of unbox_oneof, an all-dots case joins the rejection test, the codegen recursion error says "the blanket . rule" instead of citing the builder's unbox_oneof() to plugin users, the guide section notes that view oneofs stay boxed, and the fragment drops the alias sentence. Ready to queue once Iain stamps it.