This will allow users to export any metadata attached to this descriptor without also constructing every nested descriptor. This is consistent with FileDescriptor::CopyHeadingTo, which serves a similar purpose at a different scope.
PiperOrigin-RevId: 621995153
function call with precalculated values.
We have to query every field anyway, so better to do it once at the start and
keep the results.
PiperOrigin-RevId: 621650969
All parsing now happens via a TcParser table, accessible from `ClassData` either directly or through the `get_tc_table` callback.
All codegen types insert their generated table in their ClassData. Dynamic types use the callback to generate it on demand.
PiperOrigin-RevId: 621632525
DynamicMessage now eagerly creates the tc_table doing proper crosslinking of TDP tables.
Remove all kTvDefault cases from TcParser.
PiperOrigin-RevId: 620943275
Also, we remove the ArenaDtor and register the Cord for destruction on demand.
This avoids registering the ArenaDtor on every message with a lazy field.
PiperOrigin-RevId: 620857434
* The alignment may be incorrect.
* Using delete[] otherwise mismatches, since it was not allocated with
overaligned operator new.
Additionally, we add a test to ensure we do not value initialize in this case.
PiperOrigin-RevId: 620241337
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
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
Protobuf Team Bot
Mike Kruskal
Protobuf Team Bot
Marcel Hlopko
Chris Kennelly
Adam Cozzette
Alex Eagle
Anton Grbin
Sandy Zhang