Features need to be validated within the pool being built, since the generated pool only contains extensions linked into the binary (e.g. protoc or a runtime building dynamic protos). The generated pool may be missing extensions used in this proto or it may have version skew. Moving to the build pool requires reflective parsing, which in general can't be done from inside the pool's database lock. This required some refactoring to add a post-build validation phase outside of the lock.
For now, the feature support spec is optional and the checks only are only applied when it's present. Follow-up changes will add these specs to our existing features and then require them for all FeatureSet extensions.
PiperOrigin-RevId: 623630219
- For enums that are already defined in a sequential manner, use the existing info from the descriptor.
- For other enums use a bit set to find unique values instead of a vector+sort+unique. Much less work to do so, and we can use stack for it instead of heap most of the time.
PiperOrigin-RevId: 623613446
- Make FreeStringBlocks() happen inside Free() as string blocks are basically an implementation detail of SerialArena.
- Add GetDeallocator to the anonymous namespace.
- Remove a comment about the implementation of AddSpaceAllocated at one of its callsites.
PiperOrigin-RevId: 623563543
This ensures that StreamDecoder throws a InvalidProtocolBufferException instead of an IllegalStateException on some invalid input.
All other implementations of CodedInputStream already do this check.
PiperOrigin-RevId: 623383287
Move away from looking up selectors at proto initialization time to doing optimized string compares at implementation resolving time.
PiperOrigin-RevId: 623183331
Instead of using the message's corresponding field to denote the end of the stream, just abort it on *any* end group tag. If this is an invalid tag, the caller will handle the failure.
PiperOrigin-RevId: 622859234
Trying to build `protobuf/3.21.12` my tests is failing on Android due to the GID_MAX/UID_MAX macros. This is because port_def.inc is missing these entries for Android. This PR adds those missing macros. I am not sure if I should apply the same port for the `TRUE`/`FALSE` macros as well, any opinion here would be appreciated.
See compile errors below:
```
C:\Users\edukaj\.conan2\p\b\andro6a387be0e6a99\p\bin\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe --target=aarch64-none-linux-android29 --gcc-toolchain=C:/Users/edukaj/.conan2/p/b/andro6a387be0e6a99/p/bin/toolchai
ns/llvm/prebuilt/windows-x86_64 --sysroot=C:/Users/edukaj/.conan2/p/b/andro6a387be0e6a99/p/bin/toolchains/llvm/prebuilt/windows-x86_64/sysroot -IC:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9
-armv8-17-debug -isystem C:/Users/edukaj/.conan2/p/b/proto97c417c206dce/p/include -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat
-Werror=format-security -O0 -fno-limit-debug-info -std=c++17 -fPIE -MD -MT CMakeFiles/test_package.dir/addressbook.pb.cc.o -MF CMakeFiles\test_package.dir\addressbook.pb.cc.o.d -o CMakeFiles/test_package.dir/addressbook.p
b.cc.o -c C:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9-armv8-17-debug/addressbook.pb.cc
In file included from C:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9-armv8-17-debug/addressbook.pb.cc:4:
C:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9-armv8-17-debug/addressbook.pb.h:834:24: error: expected member name or ';' after declaration specifiers
static constexpr GID GID_MAX =
~~~~~~~~~~~~~~~~~~~~ ^
C:/Users/edukaj/.conan2/p/b/andro6a387be0e6a99/p/bin/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/include\limits.h:118:18: note: expanded from macro 'GID_MAX'
# define GID_MAX UINT_MAX /* max value for a gid_t */
^
C:\Users\edukaj\.conan2\p\b\andro6a387be0e6a99\p\bin\toolchains\llvm\prebuilt\windows-x86_64\lib64\clang\9.0.9\include\limits.h:56:20: note: expanded from macro 'UINT_MAX'
#define UINT_MAX (__INT_MAX__ *2U +1U)
^
<built-in>:92:21: note: expanded from here
#define __INT_MAX__ 2147483647
^
In file included from C:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9-armv8-17-debug/addressbook.pb.cc:4:
C:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9-armv8-17-debug/addressbook.pb.h:834:24: error: expected ')'
C:/Users/edukaj/.conan2/p/b/andro6a387be0e6a99/p/bin/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/include\limits.h:118:18: note: expanded from macro 'GID_MAX'
# define GID_MAX UINT_MAX /* max value for a gid_t */
^
C:\Users\edukaj\.conan2\p\b\andro6a387be0e6a99\p\bin\toolchains\llvm\prebuilt\windows-x86_64\lib64\clang\9.0.9\include\limits.h:56:20: note: expanded from macro 'UINT_MAX'
#define UINT_MAX (__INT_MAX__ *2U +1U)
^
<built-in>:92:21: note: expanded from here
#define __INT_MAX__ 2147483647
^
C:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9-armv8-17-debug/addressbook.pb.h:834:24: note: to match this '('
C:/Users/edukaj/.conan2/p/b/andro6a387be0e6a99/p/bin/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/include\limits.h:118:18: note: expanded from macro 'GID_MAX'
# define GID_MAX UINT_MAX /* max value for a gid_t */
^
C:\Users\edukaj\.conan2\p\b\andro6a387be0e6a99\p\bin\toolchains\llvm\prebuilt\windows-x86_64\lib64\clang\9.0.9\include\limits.h:56:19: note: expanded from macro 'UINT_MAX'
#define UINT_MAX (__INT_MAX__ *2U +1U)
^
In file included from C:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9-armv8-17-debug/addressbook.pb.cc:4:
C:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9-armv8-17-debug/addressbook.pb.h:862:24: error: expected member name or ';' after declaration specifiers
static constexpr UID UID_MAX =
~~~~~~~~~~~~~~~~~~~~ ^
C:/Users/edukaj/.conan2/p/b/andro6a387be0e6a99/p/bin/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/include\limits.h:117:18: note: expanded from macro 'UID_MAX'
# define UID_MAX UINT_MAX /* max value for a uid_t */
^
C:\Users\edukaj\.conan2\p\b\andro6a387be0e6a99\p\bin\toolchains\llvm\prebuilt\windows-x86_64\lib64\clang\9.0.9\include\limits.h:56:20: note: expanded from macro 'UINT_MAX'
#define UINT_MAX (__INT_MAX__ *2U +1U)
^
<built-in>:92:21: note: expanded from here
#define __INT_MAX__ 2147483647
^
In file included from C:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9-armv8-17-debug/addressbook.pb.cc:4:
C:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9-armv8-17-debug/addressbook.pb.h:862:24: error: expected ')'
C:/Users/edukaj/.conan2/p/b/andro6a387be0e6a99/p/bin/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/include\limits.h:117:18: note: expanded from macro 'UID_MAX'
# define UID_MAX UINT_MAX /* max value for a uid_t */
^
C:\Users\edukaj\.conan2\p\b\andro6a387be0e6a99\p\bin\toolchains\llvm\prebuilt\windows-x86_64\lib64\clang\9.0.9\include\limits.h:56:20: note: expanded from macro 'UINT_MAX'
#define UINT_MAX (__INT_MAX__ *2U +1U)
^
<built-in>:92:21: note: expanded from here
#define __INT_MAX__ 2147483647
^
C:/qxr/repo/conan-center-index/recipes/protobuf/all/test_package/build/clang-9-armv8-17-debug/addressbook.pb.h:862:24: note: to match this '('
C:/Users/edukaj/.conan2/p/b/andro6a387be0e6a99/p/bin/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/include\limits.h:117:18: note: expanded from macro 'UID_MAX'
# define UID_MAX UINT_MAX /* max value for a uid_t */
^
C:\Users\edukaj\.conan2\p\b\andro6a387be0e6a99\p\bin\toolchains\llvm\prebuilt\windows-x86_64\lib64\clang\9.0.9\include\limits.h:56:19: note: expanded from macro 'UINT_MAX'
#define UINT_MAX (__INT_MAX__ *2U +1U)
^
4 errors generated.
ninja: build stopped: subcommand failed.
```
Closes#16292
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16292 from elvisdukaj:fix/macros_conflict_with_android_ndk 4c3801cf17
PiperOrigin-RevId: 622422810
These are already supported, but this will lock down that there's no issues like the ones we hit with text-format.
This also fixes an unrelated bug in our BinaryToJsonString algorithm related to unknown group handling. We still can't actually test binary->JSON in conformance tests for extensions due to TypeResolver's lack of support though.
PiperOrigin-RevId: 622360970
This updates all our text parsers and serializers to better handle tag-delimited fields under editions. Under proto2, groups were the only tag-delimited fields possible, and the group name (i.e. the message type) was guaranteed to be unique. Text-format and various generators used this instead of the synthetic field name (lower-cased group name) to represent these fields.
Under editions, we've removed group syntax and allowed any message field to be tag-delimited. This breaks those cases when adding new tag-delimited fields where the message type might not be unique or correspond to the field name. Code generators have already been fixed to treat "group-like" fields using the old behavior, and treat new fields like any other sub-message.
This change addresses the text-format issue. Text parsers will accept *either* the type or field name for "group-like" fields, and only the field name for every other message field. Text serializers will continue to emit the message name for "group-like" fields, but also use the field name for everything else.
This creates some awkward capitalization behavior for fields that happen to *look* like proto2 groups, but it won't lead to any conflicts or invalid encodings. A feature will likely be added to edition 2024 to allow for migration off this legacy behavior.
PiperOrigin-RevId: 622260327
For now, these are limited to tests of text-form for delimited fields that locks down our problematic behavior in editions. Follow up changes will adjust the behavior to behave better under editions.
PiperOrigin-RevId: 622211473
A few of our generators previously used proto2 group's message name to generate code. In order to keep these backwards compatible but still functional under editions, we define a new IsGroupLike helper function. Message fields consistent with proto2 groups will continue using the old generated APIs, but all new ones possible under editions will correctly use the field name.
Edition 2024 will likely include a feature to allow for incremental migrations off this pattern, and follow-up changes will address related text-format issues.
PiperOrigin-RevId: 622204864
They are not needed after the rules are move into protobuf repo.
Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo.
PiperOrigin-RevId: 622176865
In the _RegularMessageToJsonObject method, there is no str type conversion for non-bytes type values in the repeated content. This causes an exception in the MessageToJson method, as the jsons data does not allow for the occurrence of byte array type property values.
BUG EG (contains proto and python code)：
------------common.proto------------
message SafetyInfo{//
repeated LoginDevice deviceList = 1;
}
message LoginDevice {
optional string uuid = 1 [default = ""];
optional string deviceName = 2 [default = ""];
optional string deviceType = 3 [default = ""];
required uint32 lastTime = 4;
}
------------test code(python)------------
from google.protobuf.json_format import MessageToJson
import common_pb2 # generate by common.proto
pb = common_pb2.SafetyInfo()
pb_hex = "0a4e0a2039323833663530356533363332396338356638623866343832613561323061651211636d4a38426c307a4d20446576696365731a0f6950686f6e6520694f532031332e3720dc85a9b00628010a410a206233356161326632366236343966313536393466663761336263303434323163120950432dcdacd0cbb4ef1a0a57696e646f777320313020d5d2c6e705280010001800200028003001" pb.ParseFromString(bytes.fromhex(pb_hex))
print(pb)
print(MessageToJson(pb))
Closes#16382
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16382 from zhangzibao:main 3af2569265
PiperOrigin-RevId: 622156823
This will allow users to export any metadata attached to this descriptor without also constructing every nested descriptor. This is consistent with FileDescriptor::CopyHeadingTo, which serves a similar purpose at a different scope.
PiperOrigin-RevId: 621995153
Mike Kruskal
Sandy Zhang
Protobuf Team Bot
Protobuf Team Bot
Eric Salo
Dave MacLachlan
Éamonn McManus
Hong Shin
Elvis Dukaj
zhangzibao