This is equivalent to C++'s `_IsValid` functions. Since proto3 enums are open,
`is_known` seems to be a better name than the misleading `is_valid`.
C++-specific Protocol Buffers documentation already uses "known fields" and
"unknown enum values" expressions.
PiperOrigin-RevId: 630344180
I also considered using Collections.emptyNavigableMap(), which I thought might
use a specialized allocation free empty iterator, but it allocates, and its
clone() method isn't nicely exposed.
PiperOrigin-RevId: 630234849
Previously, we would allocate a boxed Integer when accessing repeated enums, because we used ArrayList<Integer>, which must box the int.
Use IntArrayList and the primitive "int getInt()" method instead.
PiperOrigin-RevId: 630229119
Instead of checking the resolved features, we should really be checking the has_presence helper. Repeated fields, oneofs, and extensions can trigger these conditions when they inherit IMPLICIT, even though it's ignored.
Closes#16664
PiperOrigin-RevId: 630206208
Map fields should remain length-prefixed for now, even if DELIMITED is inherited. Field presence will remain unchanged, but unit-tests are added to make sure proto2/proto3 behaviors stay consistent.
Closes#16549
PiperOrigin-RevId: 630191163
This can cause ODR violations in downstream users who link against both the bootstrapped proto and transitive C++ gencode of java_features.proto. Once protoc is split up, we can turn the bootstrapped proto into a real cc_proto_library target and avoid this problem altogether.
PiperOrigin-RevId: 630099889
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).
(This is the second application of this change. The first had to be rolled back because it didn't handle conflict-resolution names correctly.)
PiperOrigin-RevId: 629807104
This will reduce unnecessary resource consumption by cancelling running workflows when new commits are pushed to a PR or workflow dispatch. It does not cancel pushes to main or branches.
Closes#16601
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16601 from sethvargo:sethvargo/actions-concurrency 82fd070dba
PiperOrigin-RevId: 629805311
upb users currently need to manually fetch a oneof field in order to clear it.
In this CL, we add a convenience method to do that in one fell swoop.
PiperOrigin-RevId: 629782904
The field is always set while building the descriptor, even for lazy descriptors.
The `type()` function is called extensively in reflection based code and
removing the call_once has significant performance impact.
PiperOrigin-RevId: 629723749
Using https://protobuf.dev/reference/protobuf/textformat-spec
as a guide; add valid suffixes, more cases for special values,
confirm some invalid things do fail.
Also resort the files since some weren't and sorting seems to be required for the
update helper.
PiperOrigin-RevId: 629720194
Provide a specialization for ListAdapter that avoids boxing ints into Integers.
Use this for repeated enum accessors.
In practice, the ints for most enums will fit into the JDK's "boxed int cache", avoiding extra allocations. For large enum numbers, they won't fit, and would allocate. Removing the boxing should also slightly speed up code.
PiperOrigin-RevId: 629583247
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
Protobuf Team Bot
Protobuf Team Bot
Eric Salo
Bastien Jacot-Guillarmod
Thomas Van Lenten
Adrian Sadłocha
Mark Hansen
Mike Kruskal
Éamonn McManus
Seth Vargo
Sandy Zhang
Hong Shin
Kyle Montemayor
Daniel Kenji Toyama
Ashley
Jakob Buchgraber