It's not yet possible to import any of the well-known types from a proto file
in another crate. To enable this I think we'll need to generate a function that
dependent crates can call to determine the directory that contains the
well-known types.
PiperOrigin-RevId: 706745114
This is mostly a style fix so that we can avoid using decltype which is a bit
cumbersome. auto template arguments is a C++17 feature so we can only do this
after we've migrated the buildchain to use C++17.
We upgraded main branch to C++17 in commit
fe535930d3
PiperOrigin-RevId: 706015756
The main branch was upgraded to use C++17 after the 29.0 branch cut, in commit
fe535930d3
There are still stale references to C++14 in the code, build chain, and
READMEs. This commit cleans up the stale configs and settings.
PiperOrigin-RevId: 706000867
Proto file paths generally need to be globally unique, or at least unique
within the same binary. A file conflict might be tolerated in protobuf
implementations without reflection, but ones that do support reflection will
have trouble building a descriptor pool that has one more than one proto file
with the same path.
This change therefore updates the example crate to put the proto files inside a
`proto_example/` directory since this lessens the chance of a conflict. Not
that we really care about the example crate conflicting with anything, but I
think this makes it a better example to follow.
PiperOrigin-RevId: 705982825
I also added a check to ensure that `protoc --version` matches the protobuf
runtime version. The minitable generator plugin version should also match, but
unfortunately we can't easily check this today because it does not provide a
way to check its version.
PiperOrigin-RevId: 705944904
The specific format is something which you could more easily copy-paste back into a test, either:
`SomeEnumName::CorrespondingNamedConstant` or
`SomeEnumName::from(someint)` for open enums with an unrecognized value.
For now this is emitting the string literals for the names in a generated match statement in .rs; this makes it work for both cpp and upb kernels, as well as hopefully reduces bloat if there is no cross-language lto.
At a future time we could consider calling into C++ to get the enum names there, which is a more optimized path and could reduce having the names in the binary twice in some cases.
PiperOrigin-RevId: 705910092
== 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
The previous treatment was a conformance violation, where implicit present float fields with a non-default value of -0.0 could get dropped.
PiperOrigin-RevId: 705728806
Also update the protobuf_example crate to use the OUT_DIR instead of the source in the /src dir.
This will avoids problems of the outdir having stale files that shouldn't be there anymore still being picked up in the build.
PiperOrigin-RevId: 705609005
This brings it into conformance with our spec and other languages. Some parse paths already did this check, and all of them prohibit *nested* unmatched end-group tags.
PiperOrigin-RevId: 705225060
This is only used in some narrow edge cases, and is a less-safe version of our unknown field decoders. Switching to those reduces some duplication and improves error handling.
PiperOrigin-RevId: 704899254
The invariant is that PtrAndLen may hold ptr+len values which are legal for _either_ C++ string_view or Rust slices: constructing one from either Rust or C++ permits the laxest constraints, and care must be taken when converting a PtrAndLen into either type.
For "into Rust slice" case to handle is that len=0 ptr must be non-null, so len=0 ptr=null gets turned into an arbitrary non-null pointer as provided by std::ptr::NonNull::dangling() (any preexisting non-null ptr is kept in that direction).
For the "into C++ slice" the risk is more obscure that a Rust non-null pointer could potentially be an illegal pointer (such that ptr+0 is not a legal operation in C++), so when going into C++ we map any len=0 cases into ptr=null to avoid this as a possible risk.
PiperOrigin-RevId: 704776210
Protobuf Team Bot
Adam Cozzette
Sandy Zhang
Tony Liao
Mike Kruskal
Jakob Buchgraber
John Cater
Protobuf Team Bot
Xufei Tan
Hong Shin