- Specifies bazel version for presubmits
- Set C++14 version (default is c++11 otherwise, which is unsupported)
- Update MODULE.bazel version + updater since publish-to-bcr can't handle constants and adds a duplicate version number
PiperOrigin-RevId: 633729225
This reduces our code weight by a little (3 classes).
Collections.emptySet also has a singleton empty iterator, so it doesn't allocate.
PiperOrigin-RevId: 633667264
It is not sufficient to check schema_.HasHasbits() followed by naively skipping
repeated and oneof fields as that can miss proto3 messages with message fields
and other scalar fields without "optional" keyword.
Use internal::cpp::HasHasbits(const FieldDescriptor*) instead.
PiperOrigin-RevId: 633633184
The new functions work even when RTTI is not present.
Also, add an assertion in DownCast to make sure we don't use it for message types. Message types have dedicated cast functions that should be used instead.
PiperOrigin-RevId: 633236522
The generated `protobuf-config-version.cmake` sets the `Protobuf_WITH_ZLIB`, `Protobuf_MSVC_STATIC_RUNTIME` and `Protobuf_BUILD_SHARED_LIBS` unconditionally while executing the `_check_and_save_build_option(...)` macro.
If there are several **Protobuf** installations available the original code may lead to failure. An example with two installations:
+ A system deployed installation with version `3.12.4`.
+ A repo's thirdparty with version `3.19.4`
The user wants it's project to use the thirdparty one by doing:
```cmake
find_package(Protobuf 3.19.4 CONFIG REQUIRED PATHS path/to/thirdparty)
```
The user is not setting the `Protobuf_XXX` variables in its `CMakeLitsts.txt`.
If the first config processed is the system deployed it sets the variables to its desired variables, for example, `Protobuf_WITH_ZLIB=OFF` but is discarded due to the non-matched version.
Then the thirdparty's config is processed but is discarded because requires `Protobuf_WITH_ZLIB=ON` which is not a real requirement and makes the find operation fail (despite of matching version).
Closes#16654
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16654 from MiguelBarro:fix/cmake-config 119dd25ecb
PiperOrigin-RevId: 632664341
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
`google.protobuf.Any` formatting with indentation was somewhat off.
Formatting an `Any` as root object:
```json
{"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
```
changes to
```json
{
"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
```
For messages were `Any` is in a nested field the change makes more of a visual impact.
The `c` field seems to be at the same level as the `anyField`, but it's nested so it should be indented:
```json
{
"anyField": {"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
}
```
changes to:
```json
{
"anyField": {
"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
}
```
Closes#16785
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16785 from q42jaap:main 72deed6ed7
PiperOrigin-RevId: 632506226
- add google.protobuf.proto module
- wrap generated SerializeToString and ParseFromString to the new module:
def serialize(message: Message, deterministic: bool=None) -> bytes:
"""Return the serialized proto."""
def parse(message_class: typing.Type[Message], payload: bytes) -> Message:
"""Given a serialized proto, deserialize it into a Message."""
PiperOrigin-RevId: 632223409
The previous change claimed to do this in addition to `true` and `false`, but it was not actually in the code.
To reiterate the text from the earlier change, now actually reflected entirely in the code:
> 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.
This change should not affect any existing client code in Java. If someone had tried to use an extension called `true` (etc), they would have found that the generated proto code did not compile. Now it is possible to reference such an extension as `true_`.
PiperOrigin-RevId: 632174190
instead of Reflection. This allows using these functions instead of
`dynamic_cast` for all generated types including LITE.
PiperOrigin-RevId: 632135009
Protobuf Team Bot
Derek Benson
Mike Kruskal
Sandy Zhang
Jie Luo
Mark Hansen
pbatg
Protobuf Team Bot
MiguelBarro
Eric Salo
Jaap Taal
Hong Shin
Éamonn McManus
Joshua Haberman