This is the first step of a migration to split apart upb_proto_library() into upb_c_proto_library() and upb_minitable_proto_library().
PiperOrigin-RevId: 563837216
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
Currently the generated code contains 2 loads of ptr_ b/c it's an atomic:
one in HasSize and one in AllocateFromExisting.
Combine these to be a single load.
name old cpu/op new cpu/op delta
BM_ArenaAlloc/100 250ns ± 2% 229ns ± 1% -8.20% (p=0.000 n=54+47)
BM_ArenaAllocWithCleanup/100 865ns ± 1% 812ns ± 2% -6.15% (p=0.000 n=57+56)
PiperOrigin-RevId: 563698727
we can just hardcode that logic in `Message::CopyFrom`.
Also, move the implementation of `GetClassData` to the base class for zero field messages.
PiperOrigin-RevId: 563434532
The edition specification in proto files will remain unchanged, but it will be immediately converted to an enum by the parser. This gives us more control over the valid set of editions and simplifies ordering (just an integer comparison now). We plan to release exactly one edition per year.
PiperOrigin-RevId: 563261375
This can be used by non-C++ runtimes and generators to seed feature resolution. The output binary proto message will contain a mapping from edition to the default feature set, including whichever generator feature extensions are passed to protoc.
PiperOrigin-RevId: 563246376
- Check that the maximum edition is always after the minimum
- Make sure that the minimum edition gets included in the default mapping when it's necessary
PiperOrigin-RevId: 563236159
The edition specification in proto files will remain unchanged, but it will be immediately converted to an enum by the parser. This gives us more control over the valid set of editions and simplifies ordering (just an integer comparison now). We plan to release exactly one edition per year.
PiperOrigin-RevId: 563215992
This partially fixes https://github.com/protocolbuffers/protobuf/issues/10088. The test case from that bug significantly improves with this change. However we still have a global map that does not shrink, which can still create the appearance of leaking memory, as it will not be freed until the module is unloaded.
PiperOrigin-RevId: 563124724
Joshua Haberman
Protobuf Team Bot
Laramie Leavitt
Protobuf Team Bot
Mike Kruskal
Adam Cozzette
Eric Salo
Jie Luo