Multiple typos has been fixed.
- docs/upb/design.md -> line no 291: changed 'newMessageAccesor' to 'newMessageAccessor '
- docs/design/editions/edition-zero-features.md -> line no 149: changed 'implict' to 'implicit'
Closes#14385
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/14385 from parikshitadhikari:patch d9bf9f91be
PiperOrigin-RevId: 573315890
This change moves almost everything in the `upb/` directory up one level, so
that for example `upb/upb/generated_code_support.h` becomes just
`upb/generated_code_support.h`. The only exceptions I made to this were that I
left `upb/cmake` and `upb/BUILD` where they are, mostly because that avoids
conflict with other files and the current locations seem reasonable for now.
The `python/` directory is a little bit of a challenge because we had to merge
the existing directory there with `upb/python/`. I made `upb/python/BUILD` into
the BUILD file for the merged directory, and it effectively loads the contents
of the other BUILD file via `python/build_targets.bzl`, but I plan to clean
this up soon.
PiperOrigin-RevId: 568651768
Only handles proto2 syntax atm, but I couldn't find any other implementation of something that seemed rather simple and sometimes useful, to integrate with third-party tools meant to run directly on .proto files.
Example usage: `protoc Example.proto --descriptor_set_in file_descriptor_set.pb --proto_out .`
Closes#13338
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/13338 from mycroftjr:patch-1 b25408d05f
PiperOrigin-RevId: 549351811
The old design doc had fallen out of date. Now that upb's core design has stabilized, it's time for a new design doc that walks through all of upb's major abstractions. We start with arenas; future CLs will cover other aspects of upb's design.
PiperOrigin-RevId: 549048285
Hello! I'm looking to reserve an option for a project I'm calling proto-telemetry. It will create open-telemetry compatible functions that add attributes to a span. Once this is accepted I'll update the project to use the reserved option number.
Thanks so much!
Closes#12758
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12758 from clly:proto-telemetry a8b38762d7
PiperOrigin-RevId: 532305028
```
* (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
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