We can use memset for zero initialized objects, and memcpy for ones cloned from the prototype.
This permits creating objects from the parser without calling virtual functions.
For the cases where the efficient implementation can't be used, we generate a "placement new" style function to offload the memory allocation out of the code generation. This reduces code bloat even when we can't use the more efficient implementation.
Migrate many callers of `New` and similar to the new functionality. In particular, the parsing paths will use this.
Finally, make `New` non-virtual now that `MessageLite` can handle it directly. It reduces binary size.
PiperOrigin-RevId: 665411723
GenerateByteSize itself remains deeply nested, but by factoring out one part of
the loop, at least we make the part that generates UpdateByteSize a bit more
readable.
Making the callsite of MayEmitIfNonDefaultCheck less nested actually resulted
in slight readability improvements also in the generated code, namely of the
form:
@@ -10563,8 +10559,7 @@ PROTOBUF_NOINLINE void OneStringEdition:
{
// string data = 1;
- cached_has_bits =
- this_._impl_._has_bits_[0];
+ cached_has_bits = this_._impl_._has_bits_[0];
if (cached_has_bits & 0x00000001u) {
total_size += 1 + ::proto2::internal::WireFormatLite::StringSize(
this_._internal_data());
These readability improvements should be kept IMO -- they make the generated
protobuf C++ code slightly easier to read.
PiperOrigin-RevId: 655180880
This prevents shadowing of `java.lang` package commonly used in protobuf gencode. Existing extensions named `java` may or may not previously fail to compile depending on if the contents of their .proto result in gencode using `java.lang`. This is needed to fix `java_features.proto` lite gencode since enum gencode uses `java.lang`. Fields named `java` should already be escaped.
*Warning: This may break user code for existing protos with extensions named `java`. References to the extension should be renamed to use `java_` e.g. registry.add(GeneratedClassName.java_)*
PiperOrigin-RevId: 632508249
Once an edition is released these should be fixed forever. On the other hand, the fixed defaults may see new features included as we change legacy behaviors in future editions.
PiperOrigin-RevId: 625842071
The new fields fixed_features and overridable_features can be simply merged to recover the old aggregate defaults. By splitting them though, plugins and runtimes get some extra information about lifetimes for enforcement.
PiperOrigin-RevId: 625527117
The only public target here is the edition defaults helper macro, which can be used by external runtimes and plugins. None of this code is C++-specific though, and should be organized higher up. Appropriate aliases are also placed at the top level for public targets
PiperOrigin-RevId: 625392504