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
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
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
Hello.
We want to make our protobuf repository public which contains a custom extension.
Our code is already available at https://github.com/cybozu/protobuf.
Please let us use extension number 1179.
Regards,
Closes#12324
```
* (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
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
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