- upb_DefPool_FindExtensionByMiniTable() has been promoted to a public function.
- There are now zero uses of the internal reflection headers outside of upb core (but still a few left in generated code).
PiperOrigin-RevId: 480211522
We had _upb_Message_New(), which created a message from a mini table and was
being used outside of upb even though it is an internal-only function.
We also had upb_Message_New(), which created a message from a message def.
Now there is a single public function, upb_Message_New(), which creates a
message from a mini table and covers all use cases. (The internal version has the same definition and is used for inlining.)
PiperOrigin-RevId: 480169804
The functions declared in reflection.h use neither arrays nor maps, so (a) stop including the array and map definitions, and (b) update the handful of other source files which were relying on that transitivity.
PiperOrigin-RevId: 472627278
The `__eq__` method from our base class was not getting called, because we defined `tp_hash` as `NotImplemented`. Per [the docs on `tp_hash`](https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_hash), `tp_hash` and `tp_richcompare` are inherited together, so defining `tp_hash` was inhibiting the inheritance of `tp_richcompare`.
PiperOrigin-RevId: 465184018
1. upb now tolerates a present-but-empty package name in a `FileDescriptorProto`.
2. upb now always returns a non-NULL string for `upb_FileDef_Package()`. If the package was empty or missing, the returned string is zero-length. This better matches the proto2 behavior: `proto2::FileDescriptor::package()` always returns a package string, which may be empty.
PiperOrigin-RevId: 460831797
1. `for x in mapping` now yields keys rather than values, to match Python conventions and the behavior of the old library.
2. Lookup operations now correctly reject unhashable types as map keys.
3. We implement `repr()` to use the same format as `dict`
PiperOrigin-RevId: 459491734
Lots of changes but it's all just moving things around.
Backward-compatible stub #include's have been provided for now.
upb_Arena/upb_Status have been split out from upb/upb.?
upb_Array/upb_Map/upb_MessageValue have been split out from upb/collections.?
upb_ExtensionRegistry has been split out from upb/msg.?
upb/decode_internal.h is now upb/internal/decode.h
upb/mini_table_accessors_internal.h is now upb/internal/mini_table_accessors.h
upb/table_internal.h is now upb/internal/table.h
upb/upb_internal.h is now upb/internal/upb.h
PiperOrigin-RevId: 456297617
The previous change did not have the desired effect, because the generated code uses the class named "Message" instead of "CMessage."
There was no real need to use the class "CMessage" instead of "Message." The new name is simpler and will make the previous change work.
PiperOrigin-RevId: 449309343
After some debugging I was able to determine that the Win32 DLL was failing to load libgcc_s_sjlj-1.dll. If we statically link libgcc instead, there should be no runtime dependency on libgcc.
PiperOrigin-RevId: 448338965
When I tried the previous `arm64` wheel on macOS, I discovered that `pip` on macOS only supports the `arm64` platform tag in a limited set of circumstances. pip seems to prefer `universal2` wheels.
To build a `universal2` wheel, we must run the `llvm-lipo` tool to bundle multiple `cc_binary()` outputs into a single output wheel. We use a transition to depend on multiple architectures for the extension, if we see that we are building for a multiarch CPU.
PiperOrigin-RevId: 447486256
While I've made some progress debugging b/231485326, I'm not going to be able to get this fully working in time for -rc1.
If I can debug this before the final release, we can re-enable the win32 wheels.
PiperOrigin-RevId: 446849335