fix(buffa-codegen): use Self:: in oneof serde + inlined format args in enum serde#104
Merged
fix(buffa-codegen): use Self:: in oneof serde + inlined format args in enum serde#104
Conversation
The arms in generate_oneof_serialize live inside
`impl Serialize for #enum_ident { fn serialize(&self, ..) { match self { .. } } }`,
where `Self` resolves to the oneof enum. Using `#enum_ident::#ident` is
spelled out the long way and trips rustc's clippy::use_self lint in
workspaces that opt it on. The deserialize arms in
oneof_variant_deser_arm are unchanged — those construct the oneof from
inside the *message*'s Deserialize impl where `Self` would be wrong.
The enum visitor's range-check and unknown-value error messages used
positional `{}` format args, which trips clippy::uninlined_format_args.
Buffa's PackageMod stitcher only puts the ALLOW_LINTS `#[allow(...)]` on
`__buffa`, so the per-proto Owned content (where these enum impls live)
isn't covered by it — the lint reaches the surrounding mod's allow set,
which not every wrapper carries. The inlined form is both lint-clean and
the more idiomatic spelling; no semantic change.
|
All contributors have signed the CLA ✍️ ✅ |
rpb-ant
approved these changes
May 8, 2026
iainmcgin
added a commit
to anthropics/connect-rust
that referenced
this pull request
May 8, 2026
…fa ALLOW_LINTS (#97) A codegen lint fix plus a regen for the v0.4.2 patch release. (Independently found the missing `tokio/macros` on the `server` feature on the `8f0180b` commit; #80 landed the same fix in the meantime, so the merge resolves to that. This PR adds the CHANGELOG entries for #80's `serve_tls` helper and `tokio/macros` fix, which were missed when it landed.) ## `connectrpc-build`: source the generated `mod.rs` `#[allow(...)]` from `buffa_codegen::ALLOW_LINTS` (`2b6d090`) The hardcoded list had drifted behind buffa's: it was missing `clippy::uninlined_format_args` (which buffa enum JSON deserialize errors trip), `clippy::doc_lazy_continuation`, and `clippy::module_inception`. The `pub mod <pkg>` tree wraps buffa's per-proto split output (Owned/View/Oneof/Ext + the PackageMod stitcher) plus our `__connect.rs` companions. The per-proto Owned content has no `#[allow(...)]` of its own — buffa's `package_mod_allow_attr()` is scoped to `__buffa`, and `protoc-gen-buffa-packaging` covers everything else with an inner `#![allow(...)]` that has no analogue in `connectrpc-build`'s outer-mod layout. So the suppression set must be the union of `buffa_codegen::ALLOW_LINTS` and the lints connect-rust output trips. Sourcing from `ALLOW_LINTS` keeps the two from drifting again. Bumps the `buffa-codegen` dependency floor to `0.5.1` (`unused_qualifications` landed in `ALLOW_LINTS` there). ## Regen + version bump (`17dad20`) Regenerates the checked-in conformance/example/bench output against the buffa 0.5.2 toolchain (`Self::` in oneof serde, inlined format args in enum serde — see [anthropics/buffa#104](anthropics/buffa#104)). Bumps to 0.4.2. ## Verification - `cargo test -p connectrpc -p connectrpc-build -p connectrpc-codegen --lib`: 252 + 18 + 35 passed - `cargo build -p eliza-example -p multiservice-example -p connectrpc-conformance -p rpc-bench`: clean - `cargo clippy -p connectrpc-conformance -p eliza-example -p connectrpc -p connectrpc-build --lib -- -D warnings`: clean - `cargo build -p connectrpc --features server` in isolation: now compiles (was failing without the `tokio/macros` fix) - Validated end-to-end against a downstream workspace via `[patch.crates-io]` — `cargo clippy --workspace --all-targets -- -D warnings` clean across ~150 connectrpc-consuming crates with the matching buffa 0.5.2. **Release order:** [anthropics/buffa#104](anthropics/buffa#104) → buffa v0.5.2 should ship first; the regen here was produced against that toolchain.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two
buffa-codegenfixes for opt-in clippy lints that the v0.5.0 per-proto split layout exposed, plus the 0.5.2 version bump.clippy::use_selfin oneof JSON serde (ab92334e)generate_oneof_serializeemits the manualimpl Serialize for #enum_ident { fn serialize(&self, …) { match self { … } } }with match arms spelled#enum_ident::#variant.Selfresolves to the oneof enum there, so the qualified form tripsclippy::use_self. Switched toSelf::#variantwith a comment explaining why the deserialize arms inoneof_variant_deser_armare deliberately left qualified — those construct the oneof from inside the message'sDeserializeimpl, whereSelfis the message type, not the oneof.clippy::uninlined_format_argsin enum JSON deserialize errors (578164cc)The enum visitor's range-check and unknown-value error messages used positional
format!("enum value {} out of i32 range", v). Switched toformat!("enum value {v} out of i32 range"). Semantically identical.Why these escape
ALLOW_LINTSBoth lints fire in the per-proto Owned content (
<dotted.proto>.rs,<dotted.proto>.__oneof.rs), which isinclude!'d at the package level — outside thepub mod __buffa { … }block wherepackage_mod_allow_attr()puts the#[allow(...)].protoc-gen-buffa-packagingconsumers get covered by themod.rsinner#![allow(...)], butconnectrpc-buildconsumers wrap the package tree with an outer#[allow(...)]whose contents drift independently (see the matching connect-rust 0.4.2 PR, anthropics/connect-rust#97). The cleanest fix is to make the codegen lint-clean regardless of the wrapper.Verification
cargo test -p buffa-codegen --lib: 327 passedcargo test -p buffa-test --lib: 292 passedcargo clippy -p buffa-codegen --lib -- -D warnings: cleantask gen-wkt-types/task gen-bootstrap-typesproduce no diff (the WKT/descriptor protos don't have JSON-serde oneofs or enums), socheck-generated-codeshould be unaffected.[patch.crates-io]—cargo clippy --workspace --all-targets -- -D warningsclean across ~150 buffa-consuming crates.