Add anthropics/buffa plugin v0.3.0

[iainmcgin]

Adds the protoc-gen-buffa plugin for Rust protobuf code generation, under the new top-level anthropics org as requested in earlier review.

About buffa

buffa is a zero-copy Rust Protobuf implementation with:

• Editions support (2023/2024) and full proto2/proto3 coverage
• Zero-copy view types - borrowed &str/&[u8] field access without owned allocation
• no_std + alloc compatible
• Proto3 JSON mapping with serde integration
• Conformance: passes the protobuf conformance suite (5539 binary+JSON tests, 0 expected failures)

Crates are on crates.io: buffa, buffa-types, protoc-gen-buffa.

Output convention

The plugin emits one .rs file per proto file with a flat naming scheme: foo/v1/bar.proto -> foo.v1.bar.rs. No subdirectories, no mod.rs - module tree assembly is a separate packaging plugin (protoc-gen-buffa-packaging, submitted separately).

Open questions for review

1. opts: I set json=true and views=true. If BSR has conventions for which opts to expose vs bake in, please advise.
2. File naming: The per-file output naming (pkg.subpkg.file.rs) is flat but per-proto-file, not per-package like prost. If BSR's lib.rs synthesis expects per-package naming instead, we can add a plugin option to switch modes.

Process note

CONTRIBUTING.md asks for an issue first - happy to open one if you would prefer to discuss before reviewing the PR. Filed this as a draft in the meantime.

Related: #2334 (anthropics/connect-rust) declares this plugin as a dep, so this one would need to land first.

[bufdev]

I think we might want to make a top-level anthropics org for this, instead of under community - also re: connect-rust.

[iainmcgin]

I think we might want to make a top-level anthropics org for this, instead of under community - also re: connect-rust.

Sure thing I'll redraft as part of updating to the new versions I'll likely release next week.

[bufdev]

I think there's supposed to be a crates section here? See the prost plugin as an ezample

[iainmcgin]

changed to crate ref instead of github ref 👍

[pkwarren]

To ensure reproducible builds, we check in a checksum file of generated code using the plugin. This verifies e2e code generation is functional and also ensures that the codegen doesn't change across builds.

https://github.com/bufbuild/plugins/blob/main/CONTRIBUTING.md#creating-a-new-plugin

To create the files, run make test PLUGINS=anthropics/buffa:latest and check in the plugin.sum files created under tests/testdata/buf.build/anthropics/.

[pkwarren]

We should update this branch to latest main then we can update this image to the latest base image:

Suggested change

	FROM rust:1.91.1-alpine3.22 AS builder
	FROM rust:1.95.0-alpine3.23@sha256:606fd313a0f49743ee2a7bd49a0914bab7deedb12791f3a846a34a4711db7ed2 AS builder

[pkwarren]

Suggested change

	FROM gcr.io/distroless/static-debian12:latest@sha256:87bce11be0af225e4ca761c40babb06d6d559f5767fbf7dc3c47f0f1a466b92c AS base
	FROM gcr.io/distroless/static-debian13:latest@sha256:47b2d72ff90843eb8a768b5c2f89b40741843b639d065b9b937b07cd59b479c6 AS base

[stefanvanburen]

1. opts: I set json=true and views=true. If BSR has conventions for which opts to expose vs bake in, please advise.

Seems reasonable to me to enable both — since generated SDKs aren't configurable, I think including all of the features makes sense to me (users who want more control can fall back to local generation).

2. File naming: The per-file output naming (pkg.subpkg.file.rs) is flat but per-proto-file, not per-package like prost. If BSR's lib.rs synthesis expects per-package naming instead, we can add a plugin option to switch modes.

What would be most helpful here is actually if both buffa and connect-rust included the lib.rs generation logic themselves (enabled with a plugin option; generate_librs=true strawman name; disabled by default) so that the BSR doesn't need any sort of special-casing for generating it on our end — is that possible to do?