This change moves almost everything in the `upb/` directory up one level, so
that for example `upb/upb/generated_code_support.h` becomes just
`upb/generated_code_support.h`. The only exceptions I made to this were that I
left `upb/cmake` and `upb/BUILD` where they are, mostly because that avoids
conflict with other files and the current locations seem reasonable for now.
The `python/` directory is a little bit of a challenge because we had to merge
the existing directory there with `upb/python/`. I made `upb/python/BUILD` into
the BUILD file for the merged directory, and it effectively loads the contents
of the other BUILD file via `python/build_targets.bzl`, but I plan to clean
this up soon.
PiperOrigin-RevId: 568651768
A couple weeks ago we moved upb into the protobuf Git repo, and this change
continues the merger of the two repos by making them into a single Bazel repo.
This was mostly a matter of deleting upb's WORKSPACE file and fixing up a bunch
of references to reflect the new structure.
Most of the changes are pretty mechanical, but one thing that needed more
invasive changes was the Python script for generating CMakeLists.txt,
make_cmakelists.py. The WORKSPACE file it relied on no longer exists with this
change, so I updated it to hardcode the information it needed from that file.
PiperOrigin-RevId: 564810016
I merged a handful of PRs on the upb repo after upb moved into the protobuf repo. This PR cherry-picks them here so that they will not be lost.
```
commit 7afb426a5a
Author: Keith Smiley <keithbsmiley@gmail.com>
Date: Thu Sep 7 11:36:01 2023 -0700
[bazel] Fix disallowing dylibs on darwin (#1180)
Since this bazel commit
ec5553352f
building dylibs like the ones in this rule on darwin platforms has been
unsupported. This feature is a default C++ toolchain feature to indicate
this. In bazel 7.x these dylibs will fail to link if they are still
built. As far as I can tell in the tests even if they are built they are
never used on macOS.
Co-authored-by: Adam Cozzette <acozzette@google.com>
commit 72decab5ec
Author: Keith Smiley <keithbsmiley@gmail.com>
Date: Thu Sep 7 09:42:20 2023 -0700
Add missing darwin_x86_64 CPU (#1181)
This CPU is often used when cross compiling from M1 machines. I'm also
hoping we can remove the legacy 'darwin' CPU.
commit ccadaf3196
Author: messense <messense@icloud.com>
Date: Fri Sep 8 00:28:54 2023 +0800
Fix `PyUpb_Message_MergeInternal` segfault (#1338)
when `PyUpb_Message_MergeFromString` returns `NULL`, currently
`PyUpb_Message_MergeInternal` will call `Py_DECREF` on `NULL`
which results in a segmentation fault.
This patch switches to `Py_XDECREF` to fix the segfault.
commit 2a5724d86e
Author: Kevin Greene <kgreenek@gmail.com>
Date: Wed Sep 6 16:46:35 2023 -0700
Fix lambda capture compiler error with c++20 (#1502)
When compiling with C++20, the following error is produced:
```
upb/mini_table.hpp:63:22: note: add explicit 'this' or '*this' capture
upb/mini_table.hpp: In lambda function:
upb/mini_table.hpp:71:22: error: implicit capture of 'this' via '[=]' is deprecated in C++20 [-Werror=deprecated]
71 | return appender_([=](char* buf) {
```
In C++20, it is no longer allowed to implicitly capture 'this' in a
lambda using [=].
This commit explicitly captures required values in the appropriate
lambdas and removes all uses of [=] with lambdas.
```
Closes#13908
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/13908 from acozzette:upb 7afb426a5a
PiperOrigin-RevId: 563784513
This is the second attempt to fix our Git history. This should allow
"git blame" to work correctly in the upb/ directory even though our
automation unexpectedly blew away that directory.
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
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
Tiago Quelhas
Adam Cozzette
Protobuf Team Bot
Mike Kruskal
Joshua Haberman
Protobuf Team