Instead of `_builder.getFoo()` and `_builder.setFoo(value)`, the generated code now uses `_builder.foo` and `_builder.foo = value`. When compiling against the Java Proto API, this makes no difference, since the Kotlin compiler treats Java methods `getFoo`/`setFoo` as defining a Kotlin property `foo`. But if a compatible proto API is implemented in Kotlin then there is no such equivalence. Such an implementation would have to define either both forms or just the one that the DSL uses. For a Kotlin API it is more natural to use properties.
Similarly, the generated Java methods `getFoosList()`, `getFoosCount()`, `getFoosMap()`, and `getEnumValue()` are accessed via property names (`foosList`, `foosCount`, `foosMap`, `enumValue`).
PiperOrigin-RevId: 629220383
Previously, these List.get methods returned Object, forcing boxing, and (if not in the primitive's box cache) allocation, with all the cost that entails.
I've taken the approach of duplicating methods to specialise for primitives, like BinaryWriter does for non-lite protos.
I initially considered checking the class of the list on every iteration of the
loop, but that feels wasteful, when we can
check it once at the start of the loop. This also means we have the same
behaviour as serverside protos. At the cost of a few more methods, but
hopefully they're trivially inlineable, so hopefully leading to a small dex increase without really increasing the method count.
Given this is a public API, I don't think we can remove the List<Long> overloads either.
PiperOrigin-RevId: 627183583
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
This ensures that StreamDecoder throws a InvalidProtocolBufferException instead of an IllegalStateException on some invalid input.
All other implementations of CodedInputStream already do this check.
PiperOrigin-RevId: 623383287
This updates all our text parsers and serializers to better handle tag-delimited fields under editions. Under proto2, groups were the only tag-delimited fields possible, and the group name (i.e. the message type) was guaranteed to be unique. Text-format and various generators used this instead of the synthetic field name (lower-cased group name) to represent these fields.
Under editions, we've removed group syntax and allowed any message field to be tag-delimited. This breaks those cases when adding new tag-delimited fields where the message type might not be unique or correspond to the field name. Code generators have already been fixed to treat "group-like" fields using the old behavior, and treat new fields like any other sub-message.
This change addresses the text-format issue. Text parsers will accept *either* the type or field name for "group-like" fields, and only the field name for every other message field. Text serializers will continue to emit the message name for "group-like" fields, but also use the field name for everything else.
This creates some awkward capitalization behavior for fields that happen to *look* like proto2 groups, but it won't lead to any conflicts or invalid encodings. A feature will likely be added to edition 2024 to allow for migration off this legacy behavior.
PiperOrigin-RevId: 622260327
They are not needed after the rules are move into protobuf repo.
Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo.
PiperOrigin-RevId: 622176865
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
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
Bazel 7 updated java_out.source_jars to return a Depset.
Release images are still on Bazel 6, but cloudtops were updated to Bazel 7 already.
PiperOrigin-RevId: 617253874
This should fix InvalidWireTypeException in the case of getLiteType() not treating messages with delimited encoding as groups: http://shortn/_2TEPuwIj6P
getJavaType() and needsUtf8Check() changes are no-ops since the type is the same regardless, but these are updated for consistency.
PiperOrigin-RevId: 612972996
Avoid potential races with other threads reading features that do not share a lock while features are temporarily null.
Special handling for proto1 mutable should not actually be needed, since setProto doesn't update dependency protos.
PiperOrigin-RevId: 610783483
JUnit4 does not support nested tests so these weren't running. Fixes setup problems and test logic. Oneof fields now inherit from their oneof, and top-level extensions inherit from top-level file when parent descriptor is null.
PiperOrigin-RevId: 609840087
normalized timestamp.
Without this change, an input of `9223372036854775807, 2` leads to a java.lang.ArithmeticException: overflow.
PiperOrigin-RevId: 607359958
The replacement always_print_without_presence_fields should be used instead, which is very similar but has consistent handling of optional fields by not affecting them.
PiperOrigin-RevId: 604381178
This fixes an edge-case where EnumDescriptor for a custom option may be unresolved if used in the same file, since adding the field to ExtensionRegistry doesn't trigger its static init block if the Enum is imported from a dependency.
Also renames feature resolution methods exposed from gencode. Private resolveAllFeaturesInternal() method may be renamed back to resolveAllFeatures() in a followup change.
PiperOrigin-RevId: 603852391
Éamonn McManus
Protobuf Team Bot
Mike Kruskal
Mike Kruskal
Protobuf Team Bot
Sandy Zhang
Liam Miller-Cushon
Sam Gammon
Ian Baker
aiuto
Jiri Pechanec
Luke Sandberg
Chris Kennelly