Add PyObject_GC_UnTrack() in deallocation functions for Python types that
have PyTPFLAGS_HAVE_GC set, either explicitly or by inheriting from a type
with GC set. Not untracking before clearing instance data introduces
potential race conditions (if GC happens to run between the partial clearing
and the actual deallocation) and produces a warning under Python 3.11.
(The warning then triggered an assertion failure, which only showed up when
building in Py_DEBUG mode; this therefor also fixes that assertion failure.)
PiperOrigin-RevId: 579827001
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.
The Python comparison protocol requires that if an object doesn't know how to
compare itself to an object of a different type, it returns NotImplemented
rather than False. The interpreter will then try performing the comparison using
the other operand. This translates, for protos, to:
If a proto message doesn't know how to compare itself to an object of
non-message type, it returns NotImplemented. This way, the interpreter will then
try performing the comparison using the comparison methods of the other object,
which may know how to compare itself to a message. If not, then Python will
return the combined result (e.g., if both objects don't know how to perform
__eq__, then the equality operator `==` return false).
This change allows one to compare a proto with custom matchers such as mock.ANY
that the message doesn't know how to compare to, regardless of whether
mock.ANY is on the right-hand side or left-hand side of the equality (prior to
this change, it only worked with mock.ANY on the left-hand side).
See https://github.com/protocolbuffers/protobuf/issues/9173
PiperOrigin-RevId: 559056804
Remove array.h and map.h as hdrs from :collections_internal
Remove alloc.h and arena.h as hdrs from :mem_internal (and add them to :mem)
Remove common.h and decode.h and encode.h as hdrs from :wire_internal
Lock down the visibility of :wire_internal to upb-only
Merge :mini_descriptor_encode_internal into :mini_descriptor_internal
PiperOrigin-RevId: 558235138
https://github.com/protocolbuffers/upb/issues/1220
There were two bugs here: Python was incorrectly mandating that a required
field be set during assignment, and it was also incorrectly assuming a non-NULL
return from an internal function call.
PiperOrigin-RevId: 518561818
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 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
Eric Salo
Joshua Haberman
Protobuf Team Bot
Adam Cozzette
Jie Luo
Sandy Zhang
Alexandre Jasmin
Joshua Haberman