This was added to protobuf_deps.bzl in cl/629786458 and no longer needs to be specified directly in WORKSPACE. However, an alias is needed to prevent users from breaking when upgrading from 26.x -> 27.x due to the obsolete load pointing to the wrong path.
This alias will be removed in a future release, tentatively 4.30.x.
PiperOrigin-RevId: 631821637
The identifiers `true`, `false`, and `null` are effectively reserved words in Java, although for some reason they are listed separately from the "keywords" in the Java Language Specification.
This doesn't matter for regular fields, because a proto field called `true` will be accessed with `getTrue` and `setTrue`. But for extensions, the generated Java code will have a public static field whose name is the same as the name of the extension field, with `_` appended if the name is a reserved word. Previously there was no `_` for `true` etc, so the generated code would not compile.
PiperOrigin-RevId: 631599695
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: 631454136
The idea here is to set the existing config "config_msvc" not only
when "msvc-cl" is specified but also when "clang-cl" is specified.
Keep in mind that clang-cl support in protobuf remains to be only
best-effort and untested for now.
PiperOrigin-RevId: 631195504
(Second attempt. The first attempt missed ListValue)
The “in” operator will be consistent with HasField but a little different with Proto Plus.
The detail behavior of “in” operator in Nextgen
* For WKT Struct (to be consist with old Struct behavior):
-Raise TypeError if not pass a string
-Check if the key is in the struct.fields
* For WKT ListValue (to be consist with old behavior):
-Check if the key is in the list_value.values
* For other messages:
-Raise ValueError if not pass a string
-Raise ValueError if the string is not a field
-For Oneof: Check any field under the oneof is set
-For has-presence field: check if set
-For non-has-presence field (include repeated fields): raise ValueError
PiperOrigin-RevId: 631143378
We modify set_<repeated_field> to accept the IntoProxied type as the value and move the value (avoid copying) whenever possible.
For UPB:
- We fuse the arena of Repeated<T> with the parent message arena.
- We use upb_Message_SetBaseField to set the upb_Array contained in the Repeated<T>.
For C++:
- We generate an additional setter thunk that moves the value.
- The move assignment operator of RepeatedField/RepeatedPtrField is specialized. In order to adhere to the layering check we need to add '#include' statements for all .proto imports to the generated thunks.pb.cc.
PiperOrigin-RevId: 631010333
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
Protobuf Team Bot
Brent Shaffer
Sandy Zhang
Protobuf Team Bot
Eric Salo
Éamonn McManus
Hong Shin
Mark Hansen
Jie Luo
Yohei Yukawa
Jakob Buchgraber
Bastien Jacot-Guillarmod
Thomas Van Lenten
Adrian Sadłocha
Mike Kruskal