Skip to content

fix: server feature → tokio/macros, source mod.rs allow list from buffa ALLOW_LINTS#97

Merged
iainmcgin merged 5 commits intomainfrom
iain/codegen-fixes-wip
May 8, 2026
Merged

fix: server feature → tokio/macros, source mod.rs allow list from buffa ALLOW_LINTS#97
iainmcgin merged 5 commits intomainfrom
iain/codegen-fixes-wip

Conversation

@iainmcgin
Copy link
Copy Markdown
Collaborator

@iainmcgin iainmcgin commented May 7, 2026

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). 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 → buffa v0.5.2 should ship first; the regen here was produced against that toolchain.

iainmcgin added 3 commits May 7, 2026 19:01
`Server::serve` uses `tokio::select!` to race accept against graceful
shutdown. The `server` feature enabled `tokio/net` but not
`tokio/macros`, so a crate depending on
`connectrpc = { features = ["server"] }` only compiled when something
else in its closure enabled the feature for it. Our conformance suite
and examples always do — `tokio = { features = ["macros", ...] }` is
in the dev-dependency table — which kept the gap hidden in CI.
…ffa_codegen::ALLOW_LINTS

The `pub mod <pkg>` tree wraps buffa's per-proto content (Owned,
View, Oneof, Ext, PackageMod stitcher) plus our `__connect.rs`
companions. The per-proto 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.

The hardcoded list had drifted: it was missing
`clippy::uninlined_format_args` (which buffa enum JSON deserialize
errors trip), `clippy::doc_lazy_continuation`, and
`clippy::module_inception`. Sourcing from `ALLOW_LINTS` keeps the two
in lockstep when buffa adds entries; `impl_trait_redundant_captures`
remains a connectrpc-build-specific addition.
Regenerate the checked-in conformance/example/bench output against the
buffa 0.5.2 protoc plugins. The visible diff: oneof JSON serde match
arms now use `Self::Variant`, enum JSON deserialize errors use inlined
format args, and the per-package `#[allow(...)]` blocks gain
`unused_qualifications` (from buffa 0.5.1's ALLOW_LINTS change).
@iainmcgin iainmcgin requested a review from rpb-ant May 7, 2026 22:53
@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 7, 2026

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

@anthropics anthropics unlocked this conversation May 7, 2026
@iainmcgin iainmcgin enabled auto-merge (squash) May 7, 2026 23:12
iainmcgin added a commit to anthropics/buffa that referenced this pull request May 8, 2026
…n enum serde (#104)

Two `buffa-codegen` fixes for opt-in clippy lints that the v0.5.0
per-proto split layout exposed, plus the 0.5.2 version bump.

## `clippy::use_self` in oneof JSON serde (`ab92334e`)

`generate_oneof_serialize` emits the manual `impl Serialize for
#enum_ident { fn serialize(&self, …) { match self { … } } }` with match
arms spelled `#enum_ident::#variant`. `Self` resolves to the oneof enum
there, so the qualified form trips `clippy::use_self`. Switched to
`Self::#variant` with a comment explaining why the deserialize arms in
`oneof_variant_deser_arm` are deliberately left qualified — those
construct the oneof from inside the *message*'s `Deserialize` impl,
where `Self` is the message type, not the oneof.

## `clippy::uninlined_format_args` in 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 to
`format!("enum value {v} out of i32 range")`. Semantically identical.

## Why these escape `ALLOW_LINTS`

Both lints fire in the *per-proto Owned content* (`<dotted.proto>.rs`,
`<dotted.proto>.__oneof.rs`), which is `include!`'d at the *package*
level — outside the `pub mod __buffa { … }` block where
`package_mod_allow_attr()` puts the `#[allow(...)]`.
`protoc-gen-buffa-packaging` consumers get covered by the `mod.rs` inner
`#![allow(...)]`, but `connectrpc-build` consumers 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 passed
- `cargo test -p buffa-test --lib`: 292 passed
- `cargo clippy -p buffa-codegen --lib -- -D warnings`: clean
- `task gen-wkt-types` / `task gen-bootstrap-types` produce no diff (the
WKT/descriptor protos don't have JSON-serde oneofs or enums), so
`check-generated-code` should be unaffected.
- Validated end-to-end against a downstream workspace via
`[patch.crates-io]` — `cargo clippy --workspace --all-targets -- -D
warnings` clean across ~150 buffa-consuming crates.
@iainmcgin iainmcgin merged commit 4599ae3 into main May 8, 2026
12 checks passed
@github-actions github-actions Bot locked and limited conversation to collaborators May 8, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants