examples: pin bsr-quickstart to one buffa release and check it in CI

[harshitwandhare]

examples/bsr-quickstart pinned the BSR plugin at v0.5.2 but compiled against the in-tree runtime through path dependencies, and the checked-in src/gen/example.v1.rs matched neither. Four errors on 18476fa, as reported.

That file had been hand-patched four times since it was generated (#184, #284, #409, #381) rather than regenerated, so it tracked the in-tree API by hand while still being described as published-plugin output. The directory sits in the workspace exclude list, so nothing compiled it and each round of drift stayed invisible.

Neither half of the fix works alone.

Pinning the runtime back to crates.io =0.5.2 to match the plugin fails with a different three errors, because the file is no longer v0.5.2 output:

error[E0433]: cannot find `unsafe_impl_view_lifetime_parametric` in `buffa`
error[E0433]: cannot find `DecodeContext` in `buffa`
error[E0407]: method `decode_view_with_ctx` is not a member of trait `::buffa::MessageView`

Bumping only the plugin pin fails too. v0.9.2 is published, but #381 requires the ViewLifetimeParametric marker and no published plugin emits it yet, so published v0.9.2 output against main gives four of

error[E0277]: `GreetingView<'_>` does not implement `ViewLifetimeParametric`

which is the situation #381's own description calls out as needing a 0.10 BSR plugin.

So the plugin pin moves to v0.9.2, src/gen/ is regenerated from it, and buffa / buffa-types move to the matching crates.io release. Both halves come from one buffa version, which is also what a downstream BSR user has, and the example stops depending on main. That is what clears the "cannot be regenerated until a 0.10 BSR plugin is published" blocker: the example no longer needs to track main, so a 0.10 plugin is only wanted when the example should start demonstrating 0.10.

The unsafe_impl_view_lifetime_parametric! line added by hand in #381 goes away with the regen, which is correct here: buffa 0.9.2 has no such macro, and the example no longer compiles against the runtime that requires it.

The cost is the forward-compat canary the old Cargo.toml comment described, and it was not working. The published plugin lags main by design, so between releases the canary's only outcome was a red example, and it was being silenced by hand-patching rather than acted on. In-tree codegen against the in-tree runtime is already covered by buffa-test and the two codegen compile matrices in lint-and-test.

A cargo check step in lint-and-test now covers the example. With both pins naming one release it can only go red if one pin moves without the other, which is what the release bump has to get right anyway.

Verified

Regenerated with buf generate against the pinned v0.9.2 plugin, then in examples/bsr-quickstart:

cargo check                                clean
cargo run                                  encodes 47 bytes, prints the views and the JSON
cargo clippy --all-targets -- -D warnings  clean

Cross-check on the regen: published v0.9.2 plugin output and the in-tree protoc-gen-buffa differ by exactly the one unsafe_impl_view_lifetime_parametric!(GreetingView); line, so the published plugin is otherwise current with in-tree codegen.

Not run: the workspace test suite, since nothing here touches a workspace crate. The ci.yml step is the only change outside examples/bsr-quickstart and .changes/.

This is option 2 from the issue. If you would rather have option 1, the regenerated src/gen/ is the same file either way and only the two Cargo.toml lines change, but it does not compile against main today for the #381 reason above.

Fixes #427.

[github-actions]

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