This will make the text format parser reject inputs that have a nesting depth
greater than 150. We will soon lower this number down to 100 for consistency
with other implementations.
For use cases that rely on parsing deeply nested text protos, it is possible to
create a Parser with a custom recursion limit like this:
`TextFormat.Parser.newBuilder().setRecursionLimit(i).build()`.
PiperOrigin-RevId: 552543574
`ConsumeFieldValue()` has some special logic for handling Any fields, but this
does not seem to be necessary since `mergeField` can handle Any fields on its
own. This CL therefore deletes the Any-related logic from
`ConsumeFieldValue()`.
PiperOrigin-RevId: 552540364
Currently this corner case (discovered by fuzzing) is not considered. The code throws `ArrayIndexOutOfBoundsException` which can escape `protobuf.toString()` method.
PiperOrigin-RevId: 550514062
This handles conversion from descriptors to MessageInfo in a single generic codepath that handles the following differences across syntaxes:
- Enum closedness (proto2)
- Explicit (proto2) vs implicit (proto3) presence
- Required field initialization (proto2)
- UTF8 (proto2/3 specific options)
This also fixes proto3 non-optional messages to encode hasbit, which was updated in cl/542744002
PiperOrigin-RevId: 544358617
This handles the following proto2/3 differences in single parseMessage codepath that works for proto2, proto3, and editions
- Groups (proto2)
- Open (proto3) vs closed (proto2) enums, incl closed enums in unknown fields
- Extensions (proto2)
- No presence (proto3)
PiperOrigin-RevId: 542872685
This unifies proto2 and proto3 (and later editions) implementations to incorporate performance optimizations directly referencing unsafe and caching presence field (and offset) originally added in cl/187404278 for proto2 only. This is similar to cl/539189318 which incorporates similar changes for writeFieldsInAscendingOrder().
This change also handles possible extensions for all syntaxes and clarifies when presenceFieldOffset may actually be storing cachedSizeOffset.
PiperOrigin-RevId: 541925703
This unifies proto2 and proto3 (and later editions) implementations to incorporate performance optimizations directly referencing unsafe and caching reflection presence field (and offset) to all syntaxes. These optimizations were originally added in cl/187404278 for proto2 only.
These optimizations do not seem to be meaningfully proto2/3-specific. The UnsafeUtil methods simply wrap the corresponding Unsafe methods. Presence bit fields are used in the same way for proto3, but this optimization seems to predate proto3 optional.
While in there, better document how the buffer encoding and mask/offsets work.
PiperOrigin-RevId: 540320373
This treats clear similarly to has and get to avoids issues from missing clear method for escaped synthetic oneofs (e.g. field _underscore -> oneof X_underscore). Previously, `clear` was using the clear method of the field (which has the same camel-cased name outside of the underscore case).
We also remove synthetic oneof camelCase names from the gencode for FieldAccesorTable since these should not be used / exposed.
Fixes#12880
PiperOrigin-RevId: 539069001
This updates kMapWithProto2EnumValue -> kLegacyEnumIsClosedBit s.t. this bit now indicates closedness for enum fields as well, not just maps with enum values.
PiperOrigin-RevId: 535782238
//java:core, //java:lite, and //java:util shouldn't have this extra dependency. For now, we just add a separate version but we will look into using the java_library in protobuf_versioned_java_library in the future.
PiperOrigin-RevId: 527643325
These changes hid public APIs that are deprecated in advance of protobuf editions. They will be fully removed in a future release. Any uses of them should be migrated to the future-facing feature helpers we provide on descriptor classes.
PiperOrigin-RevId: 527422059
//java:core, //java:lite, and //java:util shouldn't have this extra dependency. For now, we just add a separate version but we will look into using the java_library in protobuf_versioned_java_library in the future.
PiperOrigin-RevId: 527643325
These changes hid public APIs that are deprecated in advance of protobuf editions. They will be fully removed in a future release. Any uses of them should be migrated to the future-facing feature helpers we provide on descriptor classes.
PiperOrigin-RevId: 527422059
These changes hid public APIs that are deprecated in advance of protobuf editions. They will be fully removed in a future release. Any uses of them should be migrated to the future-facing feature helpers we provide on descriptor classes.
PiperOrigin-RevId: 527362587
This should reduce some unnecessary branching off of syntax for ManifestSchemaFactory for CODE_SIZE optimization for full using schemas.
PiperOrigin-RevId: 526039969
Syntax will become meaningless once we migrate to editions. In the meantime, we've implemented APIs to expose the differences between proto2 and proto3 in terms of the features we plan to release in edition 2023.
PiperOrigin-RevId: 520433607
This will be used to make the method and enum to package-private and later to visibility-restrict other deprecated APIs for editions to prevent backslide.
PiperOrigin-RevId: 518028723
No need for a loop that that calls tryConsumeString or tryConsumeByteString repeatedly, since ConsumeByteString already loops itself.
PiperOrigin-RevId: 517202228
This fixes the following issue:
- In `FieldSet#getMessageSetSerializedSize` we delegate to `LazyField` for getting its size.
- Before this change, in `FieldSet#writeMessageTo` we do not delegate to LazyField's `byteString` method. Instead, we call `getValue` on the `FieldSet`.
- It's not guaranteed that `fieldSet.getSerializedSize() == fieldSet.getValue().getSerializedSize()`.
In particular, this can lead us to run into the message "Serializing com.google.protobuf.DynamicMessage to a byte array threw an IOException (should never happen)" because of mispredicted output size.
We fix the issue by following similar logic to `MessageSetSchema`- if "getSerializedSize" delegates to the LazyField, then the serializer should as well.
PiperOrigin-RevId: 516658372