In this CL, we add the macro UPB_EXT_PRIMITIVE.
The template specializations are practically identical sans the CppType and UpbFunc called, so we now consolidate via this macro.
Added support for uint32/64, float/double, and bool.
Getting and setting exts of ^ in hpb should all work, and fetch the proper default value as well (if provided in the .proto).
PiperOrigin-RevId: 707897721
Before this change, hpb had no way of returning repeated fields (that are extensions) -- they were incorrectly treated as pure scalars (int32 vs repeated<int32>).
We rectify this hole and now return RepeatedField<T> for a given T.
This CL also cleans up the `if constexpr` special casing we were performing inside GetExtension and delegates that to the UpbExtensionTrait.
PiperOrigin-RevId: 706789273
Before, the upb_ExtensionRegistry_AddArray API would just return a boolean
indicating whether the operation succeeded or failed. This is not descriptive
enough in some cases and made the error output confusing.
Specifically, when trying to register an extension with a duplicate extension
number, AddArray first performs a map lookup before inserting the extension
entry into the registry. The code handled lookup failure (due to duplicates)
the same way as insertion failure (due to OOM), and printed an error message
that showed OOM when there is a duplicate array entry.
This was acknolwedged in a TODO in the AddArray code comment -- which is now
fixed. :)
PiperOrigin-RevId: 700764584
We introduce hpb::ExtensionRegistry::generated_registry. In the future, Parse calls will default to this being the default registry, while still being able to supply their own (if needed).
PiperOrigin-RevId: 697690765
We introduce AddExtension, which'll take an ExtensionId. From there, our helper extracts the mini_table_ext() ptr and handles the upb_ExtensionRegistry behind the scenes.
The ctor for an ExtensionRegistry has been updated to just take an arena.
Just need to supply an extension, and let us handle the rest!
PiperOrigin-RevId: 696136849
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
EnableIfHpbClass was too restrictive in the past; it was
toggled only if <T> was extended. This has been rectified
to toggle if T extends T::Access, which reflects the
true intention.
PiperOrigin-RevId: 693368653
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
Move hpb::internal::{Serialize, HasExtensionOrUnknown, GetOrPromoteExtension, DeepCopy, DeepClone} to message_lock.h as they all use the message lock
absl status helpers are now housed in status.h
PiperOrigin-RevId: 681432239
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
Move hpb::internal::{Serialize, HasExtensionOrUnknown, GetOrPromoteExtension, DeepCopy, DeepClone} to message_lock.h as they all use the message lock
absl status helpers are now housed in status.h
PiperOrigin-RevId: 679307322
```
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
Hong Shin
Protobuf Team Bot
Tony Liao