This CL changes the prefetch to NTA instead of T0 to reduce cache pollution with a simplified, yet more efficient cleanup prefetch loop which removes stores and loads on the local prefetch stack, and instead simply repeats the load and branch of the prefetch resulting in CPU savings.
PiperOrigin-RevId: 493136574
The text format specs state that short formed repeated field should be valid. For example:
```
repeated_field: [{}, {}]
```
However, this was not supported when text format parser tries to skip **unknown fields**.
PiperOrigin-RevId: 493085702
The allowlist is currently empty.
It uses a simple text format to avoid reentrant dependencies into protobuf
parsing, and allow sharing between languages.
PiperOrigin-RevId: 493075113
This change introduces the `WriteCord()` method in `ZeroCopyInputStream` with a default implementation efficiently writing the cord data onto the stream. Subsequent changes will introduce explicit Cord based input and output streams that will optimize the default implementation by providing zero-copy optimized implementations when reading and writing cord data from/to underlying encoded cord data.
PiperOrigin-RevId: 493030763
The allowlist is currently empty.
It uses a simple text format to avoid reentrant dependencies into protobuf
parsing, and allow sharing between languages.
PiperOrigin-RevId: 493019427
This was silently breaking because we didn't fail on errors in the test script. The upb version is also bumped to pull in improvements for system_python that fix the underlying issue (python 3.5 doesn't work with our pip dependencies).
PiperOrigin-RevId: 492526855
This pulls in updates to system_python, which allows for better handling of our non-hermetic setup. Specifically, our python tests are marked incompatible on systems without a python installation. This will cause them to get skipped by wildcard expansions (which is why we add 1 explicit target to the kokoro builds).
PiperOrigin-RevId: 492286518
We are requesting a range of numbers instead of just one since we have some plans for a variety of orthogonal kinds of custom options. For example:
1. Injecting extra metadata into FileDescriptorProtos via custom options. (These options are inserted by the Buf tool when building proto sources, to encode additional metadata about the unit of files compiled.)
2. Configuration options for protoc plugins, that generate extra metadata into sources. (These options may be used by users when writing proto sources.)
The suggested approach of reserving just one number and making it a message that contains *all* options is unattractive since users of one category of options is unlikely to want to import types related to another category.
FWIW, there are several other rows above that have also chosen to reserve ranges of 5 or 10 numbers.
Closes#11110
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11110 from jhump:jh/custom-options-for-buf-and-connect 68ef5ff1da
PiperOrigin-RevId: 492211135