enabled.
DownCastToGenerated injects the strong reference to T, which makes all instances of CheckTypeAndMergeFrom unique and not candidates for identical code folding.
The strong reference is not needed here in the member function.
PiperOrigin-RevId: 634033477
- 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