[v0ropaev]

With lazy_views(true) and repeated_type_custom, a crate with a repeated message field does not compile. The lazy to_owned_message collects the decoded elements into a Vec and returns it as the field value, but the owned struct holds the custom collection.

error[E0308]: mismatched types
   --> .../out/repeated_type.__lazy_view.rs:205:17
205 |                 __out
    |                 ^^^^^ expected `CustomList<Inner>`, found `Vec<Inner>`

I hit it with a small crate that compiles one proto with repeated_type_custom("crate::CustomList<*>") and turns codegen options on one at a time. With only lazy_views(true) added it fails as above. The eager view path already collects into the custom type, so only the lazy path was missing it.

The fix sends the Vec through the collection's From<Vec<T>>, which ProtoList already requires. For the default Vec the generated code stays exactly as it was, so it doesn't trip clippy::useless_conversion in user crates, and no checked-in generated code changes.

The existing repeated_type fixture in buffa-test now also builds lazy views, and lazy_view_to_owned_round_trip does a decode_lazy then to_owned_message round trip on the sample message. A codegen test, lazy_to_owned_converts_vec_only_for_custom_collection, checks that the conversion is emitted for a custom collection and not for Vec. On main the fixture fails with the E0308 above and the codegen test fails its assertion.

fmt and clippy with -D warnings are clean on buffa-codegen and buffa-test (and on buffa-test with --features arbitrary), and both test suites pass on 1.95.0.

While testing this I also noticed repeated_type_custom breaks text generation. That one is #802.

[github-actions]

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