This reduces the implementation to our much narrower current use-cases, hardcoded directly where we need it. It also unifies google3 and OSS behavior, which may have deviated over time.
PiperOrigin-RevId: 502696374
This will prevent unsupported uses of these classes downstream, which can behave surprisingly and increase the friction of changes to protobuf. Specifically RepeatedField, RepeatedPtrField, and Map will only be allowed to hold the types listed in https://protobuf.dev/programming-guides/proto. The old behavior allowed them to hold just about anything, including custom user types.
PiperOrigin-RevId: 502672732
In the multi file case, the function to get the file descriptor has to be
referenced from multiple generated source, so it can't be `static`, ensure the
name is more unique to avoid issues.
PiperOrigin-RevId: 502611183
```
* (M) docs/options.md
- Add two addition field options that are used as markers for
specific YANG types in generated protobufs.
```
This adds two additional unique `FieldOptions` field numbers for annotat YANG leaf-lists, and leaf-lists of unions that need specific handling in field option code. Definitions for these fields are in github.com/openconfig/ygygot, particularly https://github.com/openconfig/ygot/blob/master/proto/yext/yext.proto.
Closes#11518
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11518 from robshakir:main ea73e697e7
PiperOrigin-RevId: 502245756
This leaves the decision of which C++ version to use up to our users. We still have a static_assert in port_def.inc that will prevent pre-C++14 usage.
PiperOrigin-RevId: 501351066
There are two issues here related to recent changes:
1) Our extern declarations of common RepeatedField types were removed, allowing RepeatedField::Reserve to get inlined. This results in an `array-bounds` warning from gcc due to our memcpy call. We had an explicit comment that this method shouldn't be inlined, and that silences the warning.
2) Using std::inserter with flat_hash_set::end() triggers a `maybe-uninitialized` warning from gcc. This is likely an Abseil issue, and showed up recently as part of our effort to migrate to the more efficient Abseil containers. Alternatively inserting into flat_hash_set::begin() works just fine and avoids this issue.
PiperOrigin-RevId: 501301957
I.e., if foo.extn is an extension for message foo.Foo, attempting to parse the document
{"[foo.extn]": 4}
as a foo.Bar would crash. This CL causes the parser to return an error instead.
PiperOrigin-RevId: 501299336
possible values form a contiguous range that starts with 0 or 1, and end no
greater than 126, when parsing a noncontiguous stream (such as from a Cord).
This routine was misusing `ParseContext::Done`. It should only be used at tag boundaries and not within field parsing.
PiperOrigin-RevId: 501107542
addresses #11243
Defines `$key_type` in `MapFieldIter`, so as not to trigger PHP 8.2 warning. Note that this will change the visibility of `$key_type` from public in previous versions to private in this version. This is a breaking change, but anyone using `$key_type` in this way is misusing the library, so I think it's acceptable.
Closes#11485
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11485 from bshaffer:fix-php-82-dynamic-warning-in-MapFieldIter b45c34d2be
PiperOrigin-RevId: 501040413
`ZeroCopyCodedInputStream::ReadCord()` is implemented in terms of `CodedInputStream::ReadCord()` which is incorrect: the contract for the interface method `ZeroCopyInputStream::ReadCord()` is that it appends to the provided cord output where `CodedInputStream::ReadCord()` sets the cord output value, clearing any pre-existing contents. This change fixes the internal implementation to append to any pre-existing contents.
PiperOrigin-RevId: 500872467
Protobuf Team Bot
Martijn Vels
Mike Kruskal
Protobuf Team Bot
Tiago Quelhas
Rob Shakir
Jonathan
Jie Luo
Adam Cozzette
Brent Shaffer