Not invoked just yet, as extant users may expect the old `GetOrPromote` pathway.
An incremental Δ for getting message extensions up to parity with proto2.
PiperOrigin-RevId: 695723050
.index() is dependent on the order specified in the .proto file.
Minitables create their own ordering, which represent the true index that we're interested in set_alias.
This can be fetched via .layout_index when we have a upb::FieldDefPtr.
PiperOrigin-RevId: 691825782
At the moment, hpb's public api solely returns Ptr<const Extension>. We'd like to support all non-msg types like int32, int64, bool etc.
These should not return a Ptr<...> but the underlying primitive itself.
We start by adding support for int32 and int64.
PiperOrigin-RevId: 691490444
Have ExtensionIdentifier have a upb_MiniTableExtension* instead of subclassing a class that is just a plain holder for a upb_MiniTableExtension* with a getter with the same name
We generally want to lean toward composition over inheritance. Without a compelling reason for inheritance, let's prefer composition for clarity, flexibility, and evolvability. Locking oneself into an inheritance hierarchy has marred many a codebase.
PiperOrigin-RevId: 689380813
Before this CL, it was only possible to get CHandles when fetching messages from a map. proto2::cpp does not have this restriction, so we patch this gap in here.
+utilize the new Emit :)
PiperOrigin-RevId: 686475508
We unify hpb's impl to utilize Protobuf's canonical printer, as opposed to a bespoke solution.
- augment hpb::Context with EmitLegacy, which keeps the $* syntax while we convert. This allows for a far simpler transitional pathway, and we can incrementally port to .Emit() as we see fit. Of course, all new calls should use .Emit().
- use the Context to wrap io::Printer and any hpb-specific info (e.g. what backend we're using)
PiperOrigin-RevId: 686198921
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
Hong Shin
Protobuf Team Bot
Joshua Haberman