Add convenience _opt for singular message fields.
Users can detect if the message is set or unset, and unwrap via into_inner.
PiperOrigin-RevId: 602749065
This is the final CL (part 4 of 4) in the ProxiedWithPresence chain.
In the past, we had returned Mut directly for the `_mut` accessors.
This was a temporary engagement in order to get the other submsg machinery checked in.
As we prep for the finalization of v0.6, we can finally conform to the rest of the `_mut` getters.
$field$_mut now correctly returns $pb$::FieldEntry<'_, $msg_type$> as a part of this.
All test callsites have been updated to `.or_default` in order to test the mutational pathway as before.
PiperOrigin-RevId: 602739186
If this took a &self there were holes in thread and memory safety, because it's allowed to get multiple &MsgMuts (but only &mut MsgMuts).
PiperOrigin-RevId: 596991263
We augment the TYPE_STRING block inside message.cc:GetterForViewOrMut so that we properly return a Mut for strings when it comes to submessages.
PiperOrigin-RevId: 589944498
Before this CL, we weren't generating view accessors for messages with depth > 1.
We weren't getting to message::GetterForViewOrMut because we were detecting FieldDescriptor::TYPE_MESSAGE and bailing out.
That check has now been expunged, and we now properly emit the right view, even for messages embedded within messages.
Added tests for:
- another level of submsg access depth
- accessing a message declared outside of the current message (that is, not a direct nested message within the same message)
- accessing the accessor of the accessor of the accessor of a recursively defined message
PiperOrigin-RevId: 588460599
msg.submsg().x() and msg.submsg().x_mut() should now be callable for strings and bytes. Main idea here was to return &[u8] for bytes (vs [u8]) and &ProtoStr instead of &str or &[u8] for strings.
This CL also expunges IsSimpleScalar.
PiperOrigin-RevId: 582809307
We've had access to views for submessages for a while:
If you hit some_message.submsg().some_int(), you'll get a view for that int.
Until now, there hasn't been a way to get some_message.submsg_mut(), so we introduce the mutational pathway here.
We haven't added fully-functioning mutation, but this is a step towards that goal.
subview was inaccurate, so I've refactored and renamed: { accessor_fns_for_views, accessor_fns_for_muts }.
PiperOrigin-RevId: 581984371
We had previously commented out the upb portion of simple_nested_test.
This is because nonmutable getters have submessages being NULL by default.
This means that trying to fetch anything, like a simple scalar from that nested message would segfault.
This CL makes the externC return an Option<RawMessage> since we've discovered that upb can return NULL. This way, we can check for `None` and handle the NULL case appropriately.
We know that the NULL pathway can only come from terra upb, since
cpp automagically constructs submsgs if they don't exist.
We've augmented upb.rs to contain a scratch space that allocates a zeroed-out contiguous chunk of memory @64KB. Since a block of zeroed-out memory is a legit message from upb's point of view, we can provide $pbr$::ScratchSpace::zeroed_block() to upb in order to get the default submessage behavior we want from upb.
This block is lazily allocated upon first request. This means that a consumer of the cpp kernel will not incur an additional cost.
PiperOrigin-RevId: 573840755
In this CL I'd like to call existing C++ Protobuf API from the V0 Rust API. Since parts of the C++ API are defined inline and using (obviously) C++ name mangling, we need to create a "thunks.cc" file that:
1) Generates code for C++ API function we use from Rust
2) Exposes these functions without any name mangling (meaning using `extern "C"`)
In this CL we add Bazel logic to generate "thunks" file, compile it, and propagate its object to linking. We also add logic to protoc to generate this "thunks" file.
The protoc logic is rather rudimentary still. I hope to focus on protoc code quality in my followup work on V0 Rust API using C++ kernel.
PiperOrigin-RevId: 523479839
This turns out to be quite of a yak shave to be able to perfectly test both kernels without having to pass extra Blaze flags.
PiperOrigin-RevId: 521850709
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
This pull request includes two implementation: C extension and PHP
package. Both implementations support encode/decode of singular,
repeated and map fields.
General
* License changed from Apache 2.0 to New BSD.
* It is now possible to define custom "options", which are basically
annotations which may be placed on definitions in a .proto file.
For example, you might define a field option called "foo" like so:
import "google/protobuf/descriptor.proto"
extend google.protobuf.FieldOptions {
optional string foo = 12345;
}
Then you annotate a field using the "foo" option:
message MyMessage {
optional int32 some_field = 1 [(foo) = "bar"]
}
The value of this option is then visible via the message's
Descriptor:
const FieldDescriptor* field =
MyMessage::descriptor()->FindFieldByName("some_field");
assert(field->options().GetExtension(foo) == "bar");
This feature has been implemented and tested in C++ and Java.
Other languages may or may not need to do extra work to support
custom options, depending on how they construct descriptors.
C++
* Fixed some GCC warnings that only occur when using -pedantic.
* Improved static initialization code, making ordering more
predictable among other things.
* TextFormat will no longer accept messages which contain multiple
instances of a singular field. Previously, the latter instance
would overwrite the former.
* Now works on systems that don't have hash_map.
Python
* Strings now use the "unicode" type rather than the "str" type.
String fields may still be assigned ASCII "str" values; they will
automatically be converted.
* Adding a property to an object representing a repeated field now
raises an exception. For example:
# No longer works (and never should have).
message.some_repeated_field.foo = 1