Implementations should not rearrange unknown fields for the same field number, because some field types accept multiple wire types (eg. packed and unpacked).
All languages currently pass this test except Java "full" and Obj-C.
PiperOrigin-RevId: 619953711
If it doesn't properly do constant initialization on globals we should
not try to call virtual functions on these objects during dynamic
initialization.
Turn off the optimization in these cases.
PiperOrigin-RevId: 619251810
This also fixes maven to package this correctly as google/protobuf/java_features.proto (same dir as WKT/descriptor.proto) instead of com/google/protobuf/java_features.proto.
Fixes https://github.com/protocolbuffers/protobuf/issues/16155
PiperOrigin-RevId: 619015714
Ensures isOptional() does not return true for LEGACY_REQUIRED fields which would otherwise get the optional label applied by default (non-optional fields still get the optional label).
Adds validation to feature resolution instead of cross link, which is too early to have FieldPresence.LEGACY_REQUIRED resolved.
PiperOrigin-RevId: 618857590
Rename .deserialize(&mut self) method to .clear_and_parse() (by marking the .deserialized deprecated pointing at the new name, will clean up usages separately)
END_PUBLIC
Per discussion in the team chat, parse/serialize is the most typical terminology for protobuf impls, we don't have much local reason to diverge.
I'm proposing giving the 'better' name to the named ctor since I think that is the one that we expect people to reach for by default; it is generally cleaner than "new then deserialize" pattern since after a parse failure there's not any message still hanging around with implementation-defined contents, along with some other smaller ergonomics benefits.
In C++ (when exceptions aren't enabled) all constructors must be infallible, so it can't have it. In Rust there's no language idiom reason why we shouldn't have an associated fn that returns Result<Msg, ParseErr>.
PiperOrigin-RevId: 618823998
This PR implements lookup of service descriptor and method descriptor objects in Ruby as described in issue https://github.com/protocolbuffers/protobuf/issues/14891.
It contains three implementations - one for the CRuby extension API, one for JRuby, and one for FFI.
With this patch,
* `DescriptorPool#lookup('fully.qualified.service.name')` works and returns a `Google::Protobuf::ServiceDescriptor` object
* You can call `#options` on that to get the service options
* You can call `#methods` on that to get the services' methods as `Google::Protobuf::MethodDescriptor` objects,
* You can call `MethodDescriptor#options` to get method options
* You can also get the streaming flags & input/output types of the method with `#input_type`, `#output_type`, `#client_streaming`, and `#server_streaming`.
In order to make the FFI implementation work, I had to mark some more methods in the UPB header as exported - I guess that's something which will have to be done on the UPB side, like this 01fed1cc1b
CC @dazuma & @haberman from the original issue, and @JasonLunn (since you work on protobuf it seems - small world!)
I apologies for the large volume of copy-pasta'd code from the existing descriptor class implementations into the new ones - I felt this was probably better than designing new abstractions to reduce it off the bat though; this feels like it "fits in" with the existing implementation.
Closes#15817
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/15817 from KJTsanaktsidis:ktsanaktsidis/add_service_method_descriptors 54d7218431
PiperOrigin-RevId: 618221016
Joshua Haberman
Alex Eagle
Protobuf Team Bot
Chris Kennelly
Protobuf Team Bot
Mike Kruskal
Sandy Zhang
Anton Grbin
Jie Luo
Eric Salo
Liam Miller-Cushon
KJ Tsanaktsidis