This is predominantly a wrapper around `BytesMut`, for simplicity.
Bytes and string fields are mostly the same, except for possible UTF-8 handling.
This also implements some minor parts of `ProtoStr` that were missed.
PiperOrigin-RevId: 561422951
This makes a few changes:
- It changes generated messages to reference message innards as a type in `__runtime` instead of branching on what fields should be there. That results in much less bifurcation in gencode and lets runtime-agnostic code reference raw message innards.
- It adds a generic mechanism for creating vtable-based mutators. These vtables point to thunks generated for interacting with C++ or upb fields. Right now, the design results in 2-word (msg+vtable) mutators for C++ and 3-word mutators (msg+arena+vtable) for UPB. See upb.rs for an explanation of the design options. I chose the `RawMessage+&Arena` design for mutator data as opposed to a `&MessageInner` design because it did not result in extra-indirection layout changes for message mutators. We could revisit this in the future with performance data, since this results in all field mutators being 3 words large instead of the register-friendly 2 words.
- And lastly, as a nearby change that touches on many of the same topics, it adds some extra SAFETY comments for Send/Sync in message gencode.
PiperOrigin-RevId: 559483437
Only emit has_field() if the field support presence. Only emit field_opt() getter if the field is both optional and supports presence.
PiperOrigin-RevId: 555133374
This CL adds function bodies for: {as_view, into_view, as_mut, into_mut, set_on} [1].
Our prior cl/552609955 didn't have `RawMessage` inside $Msg$Mut, so that's also been rectified in this CL.
[1] Everything in this set is a part of the Proxied trait, except set_on, which belongs to the SettableValue trait.
PiperOrigin-RevId: 553935803
This CL sets up the basic plumbing end-to-end for singular message fields.
We add skeletonized support for `Proxied` messages. This is done
by creating structs for $Msg$View and $Msg$Mut, and providing
stubbed impls.
PiperOrigin-RevId: 552609955
We were always emitting Optional<T> for accessors, when they should've been behind `_opt`.
We've refactored our previous accessor into `getter` and `getter_opt`. We'll only emit `getter_opt` when we're dealing with optional fields.
PiperOrigin-RevId: 544087591
Needed to lowercase fieldnames and add underscores when they use protected cpp names. Ended up using `cpp::FieldName` from the cpp impl to get this for free.
Also added escaping to Rust accessors, so that protected keywords will compile.
PiperOrigin-RevId: 543995050
Before this CL all messages were generated in the top-level crate module. With
this change we generate messages under the module specified by the package
declaration in the .proto file.
Dots are interpreted as submodule separator in consistency with how C++
namespaces are handled.
Note that name of the proto_library target still remains to be used as the crate name. This CL only adds crate submodules dependeing on the specified package.
PiperOrigin-RevId: 524235162
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
Alyssa Haroldsen
Protobuf Team Bot
Hong Shin
Adrian Sadłocha
Marcel Hlopko
Jakob Buchgraber
listonjesse
Paul Yang
Feng Xiao
xiaofeng@google.com
kenton@google.com
Jon Skeet
temporal