Migrate all tests to run on bazel 7 and fix errors that came up in the process. 30.x will no longer guarantee support for bazel 6.
#test-continuous
PiperOrigin-RevId: 703590770
Fixes protocolbuffers#10697: UnsafeDirectNioDecoder modifies shared buffer instance when performing aliased read.
I've included a test-ish reproducer in form of a unit test that fails fairly reliably, let me know whether you'd want this merged.
Closes#19405
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/19405 from mernst-github:mernst/aliasing 1d972091c3
PiperOrigin-RevId: 703588369
This is necessary for the generated code to work correctly even when it's
placed in a module instead of directly in the crate root. Now we can finally
delete the last of the gencode post-processing from the protobuf_gencode crate.
To get this to work properly I had to update the `Context` object to keep track
of the current module depth. This way we know how many `super::` prefixes we
need to prepend to an identifier to get back to the top level.
I had to some refactoring of our naming helper functions to get everything
working properly:
- Deleted `GetCrateRelativeQualifiedPath()`, since it seems simpler if we just
always provide unambiguous paths. I added some new `RsTypePath()` overloads
as a replacement.
- Made `RustModuleForContainingType()` a private implementation detail of
naming.cc, since the `RustModule()` functions are more user-friendly and
accomplish the same thing.
- Moved the logic for prepending super:: or the foreign crate name into
`RustModuleForContainingType()`. This way, all the helpers that call that
function automatically pick up the behavior we want.
PiperOrigin-RevId: 703555727
This required a tweak to the Bazel aspect to make it alias the appropriate
runtime (C++ or upb) under the name `protobuf`.
The nice thing about this is that it allows the same generated code to work
with both Bazel and Cargo. With Bazel the runtime crate is named `protobuf_cpp`
or `protobuf_upb`, whereas with the Cargo build it is just `protobuf`.
PiperOrigin-RevId: 703143472
This change updates the generated code to always prefix the names of crates
with `::` so that they can't conflict with local modules. I'm not aware of this
being an issue for anyone yet, but figured we might as well fix it proactively.
PiperOrigin-RevId: 703122266
Starting from the 2018 edition of Rust, paths starting with `::` must refer to
a crate, so when we refer to `::std` there is no risk of accidental collision
with another identifier.
Using `::std` instead of `::__std` is useful because it works even when the
generated code is in a module rather than directly in the crate root. This
allows us to remove one of the post-processing steps from the codegen crate.
PiperOrigin-RevId: 702858213
Temporarily rename the crates `staging-` while we're iterating on this.
This works for the protobuf and protobuf_codegen crates, but the protobuf_example crate fails to publish as cargo does not want build.rs to affect files outside of the OUT_DIR.
PiperOrigin-RevId: 702840478
Add trivial README.md files for this to pass.
This will catch some but not all issues with the crates that would cause them to be rejected by crates.io
PiperOrigin-RevId: 702766719
The test wrappers were another way to document nonconformant behaviour between
different python backends. We can achieve the same by removing the wrapper
script and adding an if-condition in the test itself based on
api_implementation.Type(). Since we already do that for nonconformance between
pure Python vs. C++ backends, this change makes it easier to look for UPB
nonconformance instead of going through another layer of indirection.
PiperOrigin-RevId: 702723759
The Cargo.toml sets both path and version for its dependencies: the mechanism is that path is used if possible (which it is for our test script), but is automatically stripped from the .toml file when uploadeded to Crates.io
PiperOrigin-RevId: 702721439
Some of the more complex GHA were invoking inline bash scripts without setting `-e`, meaning that failures would go unnoticed.
#test-continuous
PiperOrigin-RevId: 702413176
Rename upb_Log2CeilingSize() to upb_RoundUpToPowerOfTwo() to minimize the chance of this confusion happening in the future.
In practice this condition could never be hit by descriptors generated by protoc since FeatureSet is small and 1-byte-on-wire fields.
PiperOrigin-RevId: 702381123
Upgrading to rules_rust 0.54.1 seems to have fixed some of our Rust linking
problems, but not all, so this change adds back in the
`--@rules_rust//rust/settings:experimental_use_cc_common_link=True` flag.
This fixes some local build errors like the following:
```
$ bazel build //rust/test/shared:bad_names_cpp_test
...
= note: bazel-out/k8-fastbuild/bin/rust/test/shared/_ambiguous_libs/bad_names_cpp_test/libport-330124825.a(port.pic.o):port.cc:function google::protobuf::internal::CounterMap():(.text+0xe6): error: undefined reference to 'atexit'
```
PiperOrigin-RevId: 702380176
Enable Bazel 7 macOS test coverage which otherwise fails with
```
Undefined symbols for architecture arm64:
"_PyModule_AddIntConstant", referenced from:
_PyInit__api_implementation in api_implementation.o
"_PyModule_Create2", referenced from:
_PyInit__api_implementation in api_implementation.o
"__Py_Dealloc", referenced from:
_PyInit__api_implementation in api_implementation.o
ld: symbol(s) not found for architecture arm64
```
Fixes https://github.com/protocolbuffers/protobuf/issues/19454
#test-continuous
PiperOrigin-RevId: 702375059
Our use of `std::derived_from` reportedly fails with libc++ because we don't
include the `<concepts>` header. This change should fix the problem by just
using `std::is_base_of_v` instead, which has the advantage of not requiring
C++20.
Fixes#19364.
PiperOrigin-RevId: 702351498
Deanna Garcia
Eric Salo
Matthias Ernst
Protobuf Team Bot
Adam Cozzette
Protobuf Team Bot
Mike Kruskal
Sandy Zhang
Hong Shin
Tony Liao
Andre Sailer
PascalSenn