This simply exposes preexisting logic. This read-only API is for convenience and doesn't reveal any information that was not already available. `[GPBCodedInputStream position]` is already a public API. The `limit` is known to the user because it's specified by them.
PiperOrigin-RevId: 635502694
Some versions of gcc seem to advertise __cpp_nontype_template_args but not
support the argument in some cases.
Only attempt the template parameter if we are using the optimized .reloc
approach.
Fixes https://github.com/protocolbuffers/protobuf/issues/16868
PiperOrigin-RevId: 634787159
# Changes
Remove dead code path -- we don't allow enums to be map keys ([proto2 spec](https://protobuf.dev/programming-guides/proto2/#maps), [proto3 spec](https://protobuf.dev/programming-guides/proto3/#maps)). In other words the case block `case FieldDescriptor::TYPE_ENUM` is dead code. Potential enum type keys will be caught in `default: return lex.Invalid("unsupported map key type");` block below similar to other unsupported map key types like double.
# Motivation
While working on fixing `IgnoreUnknownEnumStringValueInMap` conformance tests for cpp ([related issue](https://github.com/protocolbuffers/protobuf/issues/7392)) I stumbled upon a bug where we pass the wrong `field` parameter to the enum parsing function.
In this scope:
* the variable `field` is a map field of the message that holds the map. This field is not of enum type, it's a repeated message of map entires.
* the variable `key_field` is the key field of the map message entry. This field is the enum type that we need to parse here.
The function is long, so I clarified it here:
```cpp
template <typename Traits>
absl::Status ParseMap(JsonLexer& lex, Field<Traits> field, Msg<Traits>& msg) {
(..)
return lex.VisitObject(
[&](LocationWith<MaybeOwnedString>& key) -> absl::Status {
(..)
return Traits::NewMsg(
field, msg,
[&](const Desc<Traits>& type, Msg<Traits>& entry) -> absl::Status {
auto key_field = Traits::KeyField(type);
switch (Traits::FieldType(key_field)) {
(..)
case FieldDescriptor::TYPE_ENUM: {
MaybeOwnedString key_str = key.value;
auto e = ParseEnumFromStr<Traits>(lex, key_str, /** bug here **/ field);
```
The correct reference should be `key_field`.
Instead of fixing the bug and leaving the dead code, it's better to remove the dead block alltogether.
Closes#16567
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16567 from noom:anton--7392--fix-map-key-nit d992b8a2a6
PiperOrigin-RevId: 634516984
This is an edge case we can't handle properly today. Rather than allowing poorly defined behavior, we'll make this an error condition until we can actually support it. In the future, it may be necessary to upgrade feature files to newer editions.
Closes#16756
PiperOrigin-RevId: 634512378
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
Mike Kruskal
Protobuf Team Bot
Protobuf Team Bot
Sandy Zhang
Anton Grbin
Marcel Hlopko
Jie Luo
Hong Shin
Joshua Haberman
Derek Benson
Mark Hansen
pbatg
MiguelBarro