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
This adds `#![deny(unsafe_op_in_unsafe_fn)]` which removes the
implicit `unsafe` block that `unsafe fn` does.
It also adds many more `SAFETY` docs, corrects some incomplete
ones, and catches a null pointer returned by `upb_Arena_New`.
PiperOrigin-RevId: 549067106
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
At some point, the typedef for upb_MiniTable, upb_MiniTableEnum and upb_MiniTableExtension were moved out of the internal headers and into the public ones, which requires usages of internal/file.h to import / resolve those public headers before it.
PiperOrigin-RevId: 548836379
Editions are still flag-guarded by the `--experimental_editions` flag for now, but once that's removed in a later release generators will need to explicitly specify that their support. This will avoid cases where generators may happen to work for editions but produce incorrect code.
PiperOrigin-RevId: 547959326
There are 4 different feature sets for every descriptor:
* Runtime/resolved - Used to make runtime decisions
* Source/resolved - Used to make codegen decisions
* Runtime/unresolved - Used to reason about the original proto file during runtime
* Source/unresolved - Used to validate features during codegen
Plugins will receive all 4 of these. Unresolved features will show up in the `raw_features` fields nested inside `features`. The runtime features will be in the `proto_file` field of the request, while the source features will be in the unstripped `source_file_descriptors` field.
PiperOrigin-RevId: 547925275
There are 4 different feature sets for every descriptor:
* Runtime/resolved - Used to make runtime decisions
* Source/resolved - Used to make codegen decisions
* Runtime/raw - Used to reason about the original proto file during runtime
* Source/raw - Used to validate features during codegen
All of these will need to be shipped to code generators. While C++ generators can use the C++ runtime to reconstruct these, they won't end up in the FileDescriptorProtos we send to runtimes. Similarly, non-C++ generators wouldn't be able to get them without duplicating our feature resolution logic. This change adds a helper that allows us to bundle all of these into the protos we send to generators.
PiperOrigin-RevId: 547849243
This will be used for tracking the unresolved feature sets from the original proto file. Notable use-cases for this include:
* Code generators that need to validate their own features
* Runtimes that need to be able to accurately round-trip the original protos
PiperOrigin-RevId: 547610367
This is just cruft used for selectively rolling out the editions changes. Since it's not tested, it would be dangerous to keep it in place.
PiperOrigin-RevId: 547979600
Editions are still flag-guarded by the `--experimental_editions` flag for now, but once that's removed in a later release generators will need to explicitly specify that their support. This will avoid cases where generators may happen to work for editions but produce incorrect code.
PiperOrigin-RevId: 547959326
There are 4 different feature sets for every descriptor:
* Runtime/resolved - Used to make runtime decisions
* Source/resolved - Used to make codegen decisions
* Runtime/unresolved - Used to reason about the original proto file during runtime
* Source/unresolved - Used to validate features during codegen
Plugins will receive all 4 of these. Unresolved features will show up in the `raw_features` fields nested inside `features`. The runtime features will be in the `proto_file` field of the request, while the source features will be in the unstripped `source_file_descriptors` field.
PiperOrigin-RevId: 547925275
Hong Shin
MycroftJr
zhangskz
Protobuf Team Bot
Protobuf Team Bot
Joshua Haberman
Marcel Hlopko
Chris Kennelly
kang jinci
Jason Lunn
Thomas Van Lenten
Nevena Kotlaja
Mike Kruskal
Mike Kruskal
Martijn Vels
Richard Levasseur