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 cross-compiling Python tests rely on our non-public Docker image, so disable those tests if the PR is coming from an external contributor (otherwise the jobs will fail).
Also modified the Bazel tests to use a read-only cache for external contributors.
PiperOrigin-RevId: 449321283
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
upb has traditionally returned 16-byte-aligned pointers from arena allocation. This was out of an abundance of caution, since users could theoretically be using upb arenas to allocate memory that is then used for SSE/AVX values (eg. [`__m128`](https://docs.microsoft.com/en-us/cpp/cpp/m128?view=msvc-170), which require 16-byte alignment.
In practice, the protobuf C++ arena has used 8-byte alignment for 8 years with no significant problems I know of arising from SSE etc.
Reducing the alignment requirement to 8 will save memory. It will also help with compatibility on 32-bit architectures where `malloc()` only returns 8-byte aligned memory. The immediate motivation is to fix the win32 build for Python protobuf.
PiperOrigin-RevId: 448331777
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
This should get us the full set of binary wheels we need for release. Also added acceptance tests for all wheels except aarch64 (on Linux and macos): we cannot test these without emulation, which will require a somewhat more complicated setup.
PiperOrigin-RevId: 446574958
1. For some reason the version script was not working, it was failing to export the main symbol for the Python extension. I fixed this by using the `visibility` attribute instead to export the `PyInit__message` function.
2. We were not properly stripping the `python/dist/` prefix for the C module, which was making the module exported under the name `dist.google._upb` instead of `google._upb`.
3. The `py_library()` rule was failing to actually propagate the module file into the wheel, so I just removed it.
PiperOrigin-RevId: 445446611
Protobuf Team Bot
Charlie Burnett
Protobuf Team
Joshua Haberman
Copybara-Service