== Functionality ==
Given a Rust function signature `pub fn handle_request(&mut self, req: FooRequestView, mut rsp: FooResponseMut) -> bool`, where `FooRequestView` and `FooResponseMut` are Protobuf Rust proxy types. This change enables Crubit to generate C++ bindings for `handle_request` with the C++ function signature `bool handle_request(const FooRequest* req, FooResponse* rsp)`.
== Crubit changes ==
Within a blaze build the Protobuf generated crate has two names. When the generated code gets compiled the name of the crate is the name of the `proto_library`. Later in the build the crate is renamed to the name of the `rust_proto_library`, which is what developers using Rust Protobufs see. So when the `cc_bindings_from_rs_aspect` runs the name of a Protobuf crate is the name of the `proto_library` and when the Crubit bindings get compiled the Protobuf crate in its dependencies has the name of the `rust_proto_library`. Therefore, in Crubit's generated code we rename the crate to its proto_library name via `extern crate` statements. We pass this information to Crubit via cmdline flag that gets set from within the build rules.
== Protobuf Rust changes ==
When building for the C++ kernel, Protobuf Rust View and Mut types get annotated with the `__crubit::annotate` attribute. The attribute describes the C++
message type to which the Rust type should be converted and it also includes the header that declares the C++ message type. Additionally, the type is marked `repr(transparent)` so that Crubit can verify that the ABI layout of a Protobuf Rust proxy type is pointer-like i.e. the view/mut structs have a single pointer field and any number of ZSTs. With this knowledge Crubit can generate code to convert the pointer-like Rust struct to a C++ pointer (and vice versa). No explicit conversion functions need to be specified.
An example of an annotation:
```
#[__crubit::annotate(
cpp_type = "const FooRequest*",
cpp_type_include = "path/to/foo_request.proto.h",
)]
#[repr(transparent)]
struct FooRequestView { ... }
```
PiperOrigin-RevId: 705850175
There is an old convention that a `proto_library` target with empty `srcs`
should re-export its dependencies. This is sometimes useful as a way of
creating something like an alias target, except that it can point to multiple
dependencies rather than just one.
The `rust_proto_library` aspect currently cannot handle this pattern and will
raise an error if it encounters a `proto_library` without `srcs`. This CL fixes
that problem by updating the `RustProtoInfo` provider generated by the aspect
to include a list of `DepVariantInfo` instead of just one. In the typical case
the provider will have just one `DepVariantInfo`, but this gives us the ability
to return more than one in the case where we're exporting all the dependencies
of a `src`-less `proto_library`.
One thing this CL specifically does not attempt to do is add support for a
`rust_proto_library` directly wrapping a `proto_library` without `srcs`. The
reason for that is that it appears difficult to do in a way that would respect
the layering check. It's also not obvious that we would want to encourage this
pattern anyway. It's still valuable to support `src`-less `proto_library`
targets when they're somewhere else in the transitive dependencies. This way
you can freely create a `rust_proto_library` without having to fix up all your
transitive deps first.
PiperOrigin-RevId: 687344284
This will enable us to get the correct crate names for Rust gencode. The actual
reading of the mapping file in protoc happens in the followup.
PiperOrigin-RevId: 597509582
In this CL we're adding the barebones infrastructure to generate Rust proto messages using UPB as a backend. The API is what we call a V0, not yet production-quality, not yet rigorously designed, just something to enable parallel work.
The interesting part of switching backend between UPB and C++ will come in a followup.
PiperOrigin-RevId: 517089760
The internal design is consistent with other <lang>_proto_library rules. rust_proto_library attaches rust_proto_library_aspect on its `deps` attribute. The aspect traverses the dependency, and when it visits proto_library (detected by ProtoInfo provider) it registers 2 actions:
1) to run protoc with Rust backend to emit gencode
2) to compile the gencode using Rustc
Action (2) gets the Rust proto runtime as an input as well.
Coming in a followup is support and test coverage for proto_library.deps.
PiperOrigin-RevId: 514521285
Marcel Hlopko
Protobuf Team Bot
Burak Emir
Jakob Buchgraber
Adam Cozzette
Nathan Baulch
Hong Shin
Sandy Zhang
Mike Kruskal
Liam Miller-Cushon