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
Features are designed as temporary migration tools, and any unbounded type leaves the system open to unexpected use. Features should have a fixed set of values, with well defined behaviors.
PiperOrigin-RevId: 617933544
When building with `-Dprotobuf_BUILD_SHARED_LIBS=ON`, we currently put all test
protos into their own shared library. PR #15887 seems to be pushing us over a
limit on the number of exported symbols so that this library no longer links
successfully, though.
This change fixes that problem by always building the test protos into a static
library. This should be fine since it's purely for testing and not meant to be
installed. The only things that depend on it are executables, so we don't need
to worry about ODR violations.
PiperOrigin-RevId: 617929396
Extension registration now happens in two phases, where we register all linked in messages first and any dynamic message afterwards.
This guarantees that we register all extensions that will be used by descriptor parsing before we parse any descriptors.
This is currently disabled by default.
PiperOrigin-RevId: 616840653
Three of these runtimes are based on upb, and the fourth is based on the Java runtime. Both of these already have editions support, so this was mostly just a matter of:
- Advertising support to allow editions codegen
- Stripping features from the runtime options
- Hooking up conformance tests
- Adding some lightweight editions tests
There are also a few minor orthogonal fixes included here:
- Ruby's upb hack for treating all enums as open enums needed tweaking
- The `enable_editions` flag is no longer needed in our internal proto rules
PiperOrigin-RevId: 616256211
Protobuf Team Bot
Protobuf Team Bot
Mike Kruskal
Sandy Zhang
Adam Cozzette
Hong Shin
Thomas Köppe
Chris Kennelly