This makes third_party/utf8_range no longer a Git subtree, but instead the
permanent location and source of truth for utf8_range. It is also now
incorporated into the @com_google_protobuf Bazel repo. Utf8_range still has its
own separate CMake build for now, though.
PiperOrigin-RevId: 580682733
We will soon be moving utf8_range into the protobuf repo, not as a subtree
anymore but as the real source of truth. This change adds CI coverage in
advance so that there will not be a lapse in coverage.
I also upgraded our pinned versions of rules_fuzzing and rules_python, to fix
some errors that came up with Bazel 6 and Python 3.12. I had to patch
rules_fuzzing but I am working on upstreaming the fixes.
PiperOrigin-RevId: 579987379
We're adding googletest-rust as a dependency for our rust tests, so let's ensure that our opensource build has access to the same crates.
PiperOrigin-RevId: 573863399
This separate helper for upb dependencies no longer makes sense now that upb
has been merged into the protobuf repo. This change deletes that helper and
moves the upb-specific dependencies into the `protobuf_deps()` function.
I noticed that the Python package deps need to be updated to reflect our
current support level, but I will fix that in a followup CL.
PiperOrigin-RevId: 568997625
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
This restores the Python wheel CI runs from the old upb repo with only minor
changes. I had to update a path in one of the `py_wheel` rules and also make a
slight tweak to ensure that the `descriptor.upb_minitable.{h,c}` files make it
into the source wheels. The change in text_format_test.py is not strictly
necessary but is a small simplification I made while I was trying to debug an
issue with CRLF newlines.
I had to update test_util.py to use `importlib` to access the golden files from
the installed `protobuftests` package. I suspect the previous incarnation of
thse test runs was somehow reading the goldens from the repo checkout, but I
think the intention is to read them from `protobuftests` instead. This was a
bit tricky to get working because Python versions before 3.9 do not support
`importlib.resources.files()`. I set up the code to fall back on
`importlib.resources.open_binary()` in that case, but that function does not
support subdirectories, so this required putting an `__init__.py` file inside
the `testdata` directory to make sure it is treated as a Python package.
PiperOrigin-RevId: 567366695
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
Unblocks execution of these tests on JRuby FFI.
Automated reformatting of WORKSPACE with documentary comment to ease future debugging of JRuby tests locally.
Closes#13293
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/13293 from JasonLunn:object_cache_test_update 7db211a342
PiperOrigin-RevId: 547614702
The internal design is consistent with other <lang>_proto_library rules. rust_proto_library attaches rust_proto_library_aspect on its `deps` attribute. The aspect traverses the dependency, and when it visits proto_library (detected by ProtoInfo provider) it registers 2 actions:
1) to run protoc with Rust backend to emit gencode
2) to compile the gencode using Rustc
Action (2) gets the Rust proto runtime as an input as well.
Coming in a followup is support and test coverage for proto_library.deps.
PiperOrigin-RevId: 514521285
This code is experimental and should not be expected to emit working code, and callers are liable to break without warning.
It is being released now so that development can occur in the open, but users should not expect this to be supported any time soon.
PiperOrigin-RevId: 508095929
Add bazel targets to create ruby release artifacts.
Should be run with:
```
bazel run ruby:release
bazel run ruby:jruby_release
```
Closes#11468
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11468 from deannagarcia:rubyTargets b7b7eb6865
PiperOrigin-RevId: 503277136
This uses https://github.com/protocolbuffers/rules_ruby to fully Bazelify our ruby runtime code. The Rakefile is left in place for now and is still used by our aarch64 tests. With the current implementation ruby behaves similarly to our python wrapper, which selects whatever version is installed in the system. Future enhancements will allow for more hermetic builds via Bazel flags to pin a specific version
Closes#10525
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/10525 from mkruskal-google:rules_ruby 97fa1f70ab
PiperOrigin-RevId: 499283908
Addresses https://github.com/protocolbuffers/protobuf/issues/10936.
This requires updating to the newest version of rules_python to use the new py_wheel API that includes a parameter for extra distinfo files
PiperOrigin-RevId: 493060514
This pulls in updates to system_python, which allows for better handling of our non-hermetic setup. Specifically, our python tests are marked incompatible on systems without a python installation. This will cause them to get skipped by wildcard expansions (which is why we add 1 explicit target to the kokoro builds).
PiperOrigin-RevId: 492286518
The current behavior will crash any Bazel command immediately, due to our declared pip dependencies in WORKSPACE, if python3 can't be found. The new behavior will mock out these workspace dependencies and allow any non-python targets to run. Python targets will be skipped by wildcard expressions if there's no system python3, and will fail when run directly, due to compatibility mismatch.
PiperOrigin-RevId: 492085254
* Adding build configs for sanitization
* Update bazel runner to accept configs to loop over
* Fix Bazel query from to googletest upgrade
* Fix pre-existing ODR violation
* Clean up bazel configs
* Fix UBSAN issues in tests
* Upgrade zlib to pull in UBSAN fix
* Fix conformance test UB
* Add *san builds to Bazel tests
* Add dbg to *san builds
* Extend timeout for Bazel build
* Enable ODR checks again by using static linkage in ASAN
* Cleanup kokoro setup
* Disable MSAN for now
* Enable MSAN in kokoro build
* Fix msan failure
* Remove broken bazel clean
* Cleanup
* Fix false leaks
* Fix cap-add argument
* Fix asan config name
* Remove LSAN verbosity
* Expand size of big test, add verbose failures
* Skip slow test in TSAN
* Workaround for bazel issue with ubsan
* Downgrade a presubmit to Bazel 4.0.0 to reproduce failure
* Add explicit dependency on more recent platforms package
* Upgrade to Bazel 4.2.2, the oldest supported version
* Upgrade third_party/googletest submodule to current main branch
We can finally do this upgrade now that we have dropped our autotools
build. Googletest recommends living at head, so let's go straight to the
most recent commit on main. For some reason the googletest archive is
not present in the Bazel build mirror, so I removed that entry and just
left the GitHub download link in our WORKSPACE file.
Googletest now requires C++14, so I updated all the C++11 flags I could
find to C++14 instead. I added a .bazelrc file to add -std=c++14 for all
our Bazel builds.
* Delete the empty //src/google/protobuf:protobuf_test target
* Avoid building C++ unit tests in aarch64 jobs for Python and Ruby
* Upgrade third_party/googletest submodule to current main branch
We can finally do this upgrade now that we have dropped our autotools
build. Googletest recommends living at head, so let's go straight to the
most recent commit on main. For some reason the googletest archive is
not present in the Bazel build mirror, so I removed that entry and just
left the GitHub download link in our WORKSPACE file.
Googletest now requires C++14, so I updated all the C++11 flags I could
find to C++14 instead. I added a .bazelrc file to add -std=c++14 for all
our Bazel builds.
* Delete the empty //src/google/protobuf:protobuf_test target
* Avoid building C++ unit tests in aarch64 jobs for Python and Ruby