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
LazyField explicitly registers `ArenaDtor` for destructing the lazy Cord contents which is particularly heavily used in extension sets. This is inefficient as it requires an indirect thunk call into the lazy field instance which then itself calls the Cord destructor. We can directly register the Cord for destruction which results in half the cleanup space (Tagged cleanup), and a direct call into the Cord destructor.
PiperOrigin-RevId: 491379222
* doc: Add document that describes protobuf_generate
How to use it.
How it works. (basic and with gRPC)
Reference documentation.
* doc: Address several typos and wording issues in cmake_protobuf_generate.md
* Fixing typos
* Revert new files that were deleted by sync script
* Fix CMake breakages
* bump upb version
* Sync from Piper @468772608
PROTOBUF_SYNC_PIPER
* Adding abseil to include path for python C++ extension
* Adding abseil linkage for python C++ extension
* Fixing linkage order
* Bazelfying conformance tests
Adding infrastructure to "Bazelify" languages other than Java and C++
* Delete benchmarks for languages supported by other repositories
* Bazelfying benchmark tests
* Bazelfying python
Use upb's system python rule instead of branching tensorflow
* Bazelfying Ruby
* Bazelfying C#
* Bazelfying Objective-c
* Bazelfying Kokoro mac builds
* Bazelfying Kokoro linux builds
* Deleting all deprecated files from autotools cleanup
This boils down to Makefile.am and tests.sh and all of their remaining references
* Cleanup after PR reorganizing
- Enable 32 bit tests
- Move conformance tests back
- Use select statements to select alternate runtimes
- Add internal prefixes to proto library macros
* Updating READMEs to use bazel instead of autotools.
* Bazelfying Kokoro release builds
* First round of review fixes
* Second round of review fixes
* Third round of review fixes
* Filtering out conformance tests from Bazel on Windows (b/241484899)
* Add version metadata that was previously scraped from configure.ac
* fixing typo from previous fix
* Adding ruby version tests
* Bumping pinned upb version, and adding tests to python CI
unistack-org/micro (microservices framework) uses protoc-gen-go-micro generator that has extension support for additional framework related options.
It is currently not using any registered extension number, so i want to stabilise this and i think that this is a good thing.
See here for an example of the extenstion in action.
Co-authored-by: Adam Cozzette <acozzette@google.com>