This reverts commit a7a650a74e.
Original PR breaks #38286 and I think the breakage is in the PR -- in a construct like:
```
TrySeq(
/*a*/ []() -> Promise<absl::Status>,
/*b*/ []() -> Promise<StatusFlag>,
/*c*/ []() -> Promise<absl::Status>)
```
the original seq_state code would try to promote the intermediate `StatusFlag` to an `absl::Status` which is great - however with the optimization, if `b` is instantaneous we try to demote the result of `a` to `StatusFlag`, losing information.
I'll need to consider how to change this optimization to preserve the final output type before rolling forward.
Closes#38748
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38748 from ctiller:rb1 743eb33bdf
PiperOrigin-RevId: 727109120
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#38739
PiperOrigin-RevId: 726671784
Increasingly as we write sequences, we find ourselves writing some asynchronous parts interleaved with some synchronous parts. This PR seeks to provide a basic optimizer for sequences - it detects immediate returning promises (by the lack of a `Poll<T>` return type), and eliminates the state machinery required to evaluate them at compile time.
Closes#38445
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38445 from ctiller:optseq 81c5025d76
PiperOrigin-RevId: 726641700
With the Bazel build transitioning to BzlMod, all vendored Bazel Python targets must be removed. These targets are not available in the BCR and need be managed via a pip `requirements.bazel.txt` file. gRPC already uses this approach, so it is going to be extended to include those target. (e.g. see [test utils](e06ad82c3f/test/cpp/naming/utils/BUILD (L27-L45)) to understand how those targets are used)
Additionally, the generation of the `requirements.bazel.lock` file has been improved. Because this file is a lock file, including all transitive dependencies, manual maintenance is not managable. Its new source file, `requirements.bazel.txt` is created to list only the direct dependencies used by gRPC, along with instructions for generating the full lock file. This source file omits specific version requirements to use the latest available versions, but version constraints can be added as needed.
Closes#38692
PiperOrigin-RevId: 724427578
gRPC stopped supporting VS2019 so all artifacts need to be built with VS2022 on Windows.
Closes#38697
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38697 from veblush:win-vs170 bed7a42f9f
PiperOrigin-RevId: 724368810
Aligned with the minimum supported Python version. Changes:
- Removed python 3.7 installed from `python_debian11_default_x64` docker image.
- Deleted `python_36.include` and `python_37.include` template files as they're no longer needed.
- Upgraded Python from 3.7 to 3.11 in `sanity` docker image.
- Some Python modules were modified to accomodate this
- Updated `buildifier` to v8.0.0 to have the same version that the CI tests use.
- Python 3.11 is the system default, but Python 3.7 remains installed for `pytype` and `pylint` that cannot be upgraded yet.
Closes#38693
PiperOrigin-RevId: 724071015
In addition to the regular upgrade, it's now possible to have the same version for both bazel workspace and module.
Closes#38661
PiperOrigin-RevId: 723994678
Maybe in some of these cases, `{}` would work instead of `std::pair`, but I'm just doing a simple find and replace here.
Closes#38636
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38636 from yashykt:NoMakePair d819f6a74b
PiperOrigin-RevId: 722772621
This is the [latest version ](4de3c74cf2) of envoy-API and made both bazel workspace and bzlmod use the same version.
Closes#38618
PiperOrigin-RevId: 721076378
This is a rebase of https://github.com/grpc/grpc/pull/32941 to fix conflicts and align to what changed in the meantime.
I'm very confused on how the tooling works here:
- no idea how to generate `tools/dockerfile/grpc_artifact_python_musllinux_1_1_aarch64/Dockerfile` so I copied the x64 one and update accordingly
- `tools/dockerfile/grpc_artifact_python_musllinux_1_1_aarch64.current_version` and `tools/dockerfile/distribtest/python_alpine_aarch64.current_version` need to be refreshed
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#38223
PiperOrigin-RevId: 720993782
Multiple python_windows_opt_native_test runs are failing with Timeouts with intermittent passes.
When checking the passing runs, the test run times are close to 59-60 minutes.
Hence increasing the timeout should resolve the Timeout failures
Closes#38602
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38602 from sreenithi:update_windows_opt_native_test_timeout 03898aea34
PiperOrigin-RevId: 720961937
Repeat attempt of #38338 to bring Ruby 3.4 precompiled gems to grpc.
Pending #38597
Brief history
- #38338 merged
- #38458 backported to 1.70.x and merged
- Above two changes reverted in #38516 and #38515 due to release urgency. Root cause was minor artifact build timeout due to release infra having smaller hosts (fixed in #38597)
- Discussion in #38487 about adding back the workaround with `RUBY_PATCHLEVEL`. Unclear if necessary.
This PR
- cherry-picks the original squashed PR
- adds back the `RUBY_PATCHLEVEL` hack, per discussion in #38487
- further upgrades `rake-compiler-dock` to `1.9.1` which avoids coupling patch versions between grpc and rake-compiler-dock
- This version changes the host Ruby version from `3.1` -> `3.4` so _technically_ we _could_ validate the theory from #38487. Will await @apolcyn advice.
Needs rake-compiler-dock test image re-uploads courtesy of @apolcyn🙏Closes#38601
PiperOrigin-RevId: 720824180
To roll forward https://github.com/grpc/grpc/pull/38515
As described https://github.com/grpc/grpc/pull/38515#issuecomment-2609034151, the addition of ruby-3.4 to our cross-compilation matrix caused ruby artifact build times to exceed the 2 hour timeout *on release builds*.
For some context around where this was failing, note there are three kokoro jobs that build ruby artifacts:
- pull_request `grpc_distribtests_ruby`: runs on 32-core VMs (for presubmit tests)
- master branch `grpc_distribtests_ruby`: runs on 32-core VMs (for continuous master branch coverage)
- release `grpc_distribtests_ruby`: runs on 16-core VMs (for release builds)
Even though all three jobs currently build the *same* set of ruby gems (that is slightly changing with this PR), the release build takes much longer presumably because of the smaller machine type.
So even though https://github.com/grpc/grpc/pull/38515 was passing during presubmit runs and even on master branch CI, release builds ran into timeouts. So lengthen the timeout for the release builds, which are the slowest.
Note our build matrix will shrink again around April when we drop ruby 3.0 (the ruby build matrix is largest between January and April b/c we are adding a new ruby minor version target, but waiting until ~April to delete the new oldest one).
Closes#38597
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38597 from apolcyn:bump_ruby_build_timeout b6b3770cf1
PiperOrigin-RevId: 720624102
This is the first try to enable us to upload gRPC bzlmod when publishing a new gRPC C++ release while keeping using WORKSPACE.
- Based on gRPC bzlmod 1.69 ([link](https://github.com/bazelbuild/bazel-central-registry/tree/main/modules/grpc/1.69.0))
- Removed `grpc-java` dependency as it is not needed.
- Removed `disable-layering-check.patch` which was added as a workaround for mac layering issue.
- Removed the patch for `bazel/python_rules.bzl`. This will be handled by https://github.com/grpc/grpc/pull/36843 and https://github.com/grpc/grpc/pull/35666.
- Added a new test `bazel_build_with_bzlmod_linux` to make sure that gRPC can be built with bzlmod.
Currently, there's no mechanism to automatically enforce dependency consistency between the Bazel workspace and bzlmod. This remains an unresolved issue, though it may become less relevant as the workspace is phased out in favor of bzlmod.
Closes#38456
PiperOrigin-RevId: 719504680
This reverts #38338 as it's breaking the `prod:grpc/core/master/linux/release/grpc_distribtests_ruby` job as part of the release process
Closes#38516
PiperOrigin-RevId: 718431575
Bazel 8 and the upcoming Protobuf v30 will need `rules_java` version 8.x. While gRPC itself doesn't directly use `rules_java`, its dependency, Envoy API, needs it and uses `rules_java` 7.x. This creates a conflict because rules_java 7.x is incompatible with both Bazel 8 and Protobuf v30. To resolve this, `rules_java` 8.x must be included in the build before Envoy API, fixing the build issue.
Note that gRPC doesn't call `rules_java_toolchains`, typically found in rules_java workspace configurations ([ref](https://github.com/bazelbuild/rules_java/releases/tag/8.7.0)). This is because it can't be included in `grpc_extra_deps` where `rules_java_dependencies` is called. This is acceptable since gRPC's primary concern is Bazel build setup, not Java functionality.
Partial commit of https://github.com/grpc/grpc/pull/38254Closes#38508
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38508 from veblush:b8-java 10ef60cdd2
PiperOrigin-RevId: 718116320
Bazel 8 now requires gRPC to explicitly call `rules_shell_toolchains` when using shell. This was previously handled implicitly by Bazel. Without this explicit step, Bash-based targets will fail on Windows.
Partial commit of #38254Closes#38484
PiperOrigin-RevId: 716878551
We used to use a thresholded sum of differences to determine significance of benchmark results. This is significantly flawed, especially when adding new checks - the significance threshold must also be updated, but it's unclear exactly how.
This new approach relies on counting the number of significant increases/decreases across the benchmarks, and then reporting based on how we should react: increases are biased towards (let's not increase memory blindly!), then decreases (huzzah, go collect your bonus!), then neutral changes.
Closes#38447
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38447 from ctiller:diffy 7c846eaf55
PiperOrigin-RevId: 715951309
Updates ruby-compiler-dock to `1.7.1` to [bring Ruby 3.4 support](https://github.com/rake-compiler/rake-compiler-dock/releases/tag/v1.7.0) and starts cross-compiling native gems for Ruby 3.4. Added a distribtest as well.
I believe from last year at #35399 that this probably requires @apolcyn or another Googler to build+push+update the `grpc-testing` images, along with
- `tools/dockerfile/push_testing_images.sh`
- update the values within [the current_version files](9b77138b71/third_party/rake-compiler-dock).
re-run generate_dockerimage_current_versions_bzl.sh and commit changes to dockerimage_current_versions.bzl.
- similar for the `ruby_debian11_x64_ruby_3_4` image added here (needs to be built and pushed)
Marking as draft until we are happy with approach. Note that fully pre-compiled install wont be possible until protobuf pushes their own 3.4 native versions via https://github.com/protocolbuffers/protobuf/pull/19752 (and a release), but this does not seem to block things as protobuf compile seems to be working OK without code change right now.
Closes#38338
PiperOrigin-RevId: 715431412
Fix the following error
```
File "tools/run_tests/run_tests.py", line 1846, in <module>
l.configure(run_config, args)
File "tools/run_tests/run_tests.py", line 333, in configure
) = self._compiler_options(
File "tools/run_tests/run_tests.py", line 605, in _compiler_options
self._clang_cmake_configure_extra_args()
TypeError: can only concatenate list (not "str") to list
```
Closes#38418
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38418 from veblush:fix-run-test 0eecc690bf
PiperOrigin-RevId: 713730889
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#37601
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37601 from yashykt:LogicalConnection 50aacc3dd1
PiperOrigin-RevId: 713079761
CMake needs following two changes which were missed part from https://github.com/grpc/grpc/pull/37919 to make CMake use C++17.
- **Explicitly require C++17 for gRPC targets using `cxx_std_17`**: This ensures that gRPC build targets are built with the correct C++17 support.
- **Enforce C++17 for all CMake invocations using `CMAKE_CXX_STANDARD=17`**: This is necessary due to Abseil's API changes depending on the C++ standard used. (e.g. Abseil's `absl::string_view` is implemented differently depending on the C++ standard. Before C++17, it's a distinct type. From C++17 onwards, it's simply an alias for `std::string_view`.) To maintain consistency and avoid build errors, all CMake builds (except particular build tests targetting C++20 or C++23) are now configured to use C++17.
The requirement of C++17 for building gRPC should be documented in the release notes and build instructions.
Closes#38335
PiperOrigin-RevId: 712926964
This bumps the minimum version of C++ to 17 from 14 per https://github.com/grpc/proposal/blob/master/L120-requiring-cpp17.md
Changes:
- Used C++17 instead of C++14 when building gRPC.
- Disabled `modernize-unary-static-assert` clang-tidy rule for the smooth transition. This rule will be re-enabled in a future update, along with a fix to address any identified issues.
- Added a post-install script for XCode/Cocoapod examples to enforce the use of C++17 across all projects, preventing build errors. (I'd like to have a better solution here but couldn't find it)
Closes#37919
PiperOrigin-RevId: 709073401
- Updated opentelemetry-cpp to 1.18.0 (now it's a released one)
- Clean up the old `com_github_jupp0r_prometheus_cpp` dep
Closes#38317
PiperOrigin-RevId: 707689177
There's enough here that it's worth getting this reviewed and checkpointed - although certainly this is far from production ready.
About 50% of the retry e2e tests are failing right now, some justifiably, some less so.
That said, half are passing, the general structure seems sound, and there's some nice new tests.
Closes#37816
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37816 from ctiller:and-again 9d8bc04e0c
PiperOrigin-RevId: 704309686
This is the second phase of the Clang 19 upgrade, focused on updating the Clang image used in build testing environments.
Closes#38038
PiperOrigin-RevId: 702096087
This pulls in a patch that increases the max iteration limit, which is useful for extra-small microbenchmarks.
Closes#38163
PiperOrigin-RevId: 698524219
Craig Tiller
Esun Kim
Tanvi Jagtap - Google LLC
Eugene Ostroukhov
Eugene Ostroukhov
Yash Tibrewal
Pawan Bhardwaj
Riccardo Magliocchetti
Sreenithi Sridharan
Chad Wilson
apolcyn
Stanley Cheung
AJ Heller
Mark D. Roth
alto-ruby