Similar to set_alias for singular submessages, we augment hpb with the ability to add already-allocated messages via the generated function add_alias for repeated messages.
PiperOrigin-RevId: 684136800
Similar to set_alias for singular submessages, we augment hpb with the ability to add already-allocated messages via the generated function add_alias for repeated messages.
PiperOrigin-RevId: 683269532
In certain cases, it is useful to share submessages across multiple parent messages.
proto2::cpp has a mechanism for this, so we add the hpb equivalent.
For this initial impl, we stipulate that the arenas must be exactly the same. We may explore broadening the constraint to allow for all fused arenas.
PiperOrigin-RevId: 681169537
```
hpb::Arena arena;
auto foo = hpb::CreateMessage<Foo>(arena);
foo.GetInternalArena(); // this call will now be impossible
```
Before this CL, any Proxy/Ptr could get its internal arena. This
unnecessarily leaks upb internals when they should be
interacted with via hpb::interop::upb::*.
PiperOrigin-RevId: 676038573
The goal of the `names.h` convention is to have a single canonical place where a code generator can define the set of symbols it exports to other code generators, and a canonical place where the name mangling logic is implemented.
Each upb code generator now has its own `names.h` file defining the symbols that it owns & exports:
* `third_party/upb/upb_generator/c/names.h` (for `foo.upb.h` files)
* `third_party/upb/upb_generator/minitable/names.h` (for `foo.upb_minitable.h` files)
* `third_party/upb/upb_generator/reflection/names.h` (for `foo.upbdefs.h` files)
This is a significant improvement over the previous situation where the name mangling functions were co-mingled in `common.h`/`mangle.h`, or sprinkled throughout the generators, with no clear structure for which code generator owns which symbols.
With this structure in place, the visibility lists for the various `names.h` files provide a clear dependency graph for how different generators depend on each other. In general, we want to keep dependencies on the "C" code generator to a minimum, since it is the largest and most complicated of upb's generated APIs, and is also the most prone to symbol name clashes.
Note that upb's `names.h` headers are somewhat unusual, in that we do not want them to depend on C++'s reflection or upb's reflection. Most `names.h` headers in protobuf would use types like `proto2::Descriptor`, but we don't want upb to depend on C++ reflection, especially during its bootstrapping process. We also don't want to force users to build upb defs just to use these name mangling functions. So we use only plain string types like `absl::string_view` and `std::string`.
PiperOrigin-RevId: 672397247
This yields several benefits:
1. The code no longer needs to be bootstrapped (since it no longer depends on upb reflection).
2. The upb code generator no longer depends on libprotobuf at all (except for `code_generator_lite.{h,cc}`, which is just one .cc file and has no deps).
PiperOrigin-RevId: 672280579
This CL is mostly a no-op, except that now google3-only code is actually stripped from OSS, instead of being preserved in `# begin:google_only` blocks.
This follows the conventions of the greater Copybara ecosystem.
PiperOrigin-RevId: 669513564
This simplifies upb by removing differences between google3 and OSS.
This also points upb at the protobuf license, instead of keeping a separate copy around for upb.
PiperOrigin-RevId: 669447145
Migrate ::hpb::internal::GetMiniTable to ::hpb::interop::upb::GetMiniTable
hpb.h now shows signs of backend-awareness, #including upb.h if the backend is known to be upb. If no backend is picked, we error out at this time since we solely support upb.
ClearMessage has been migrated to backend-aware hpb.
PiperOrigin-RevId: 665527832
Hong Shin
Joshua Haberman
Adam Cozzette
Mike Kruskal
Protobuf Team Bot