Repository navigation
xprof: Add version 2.23.2 - #2450
Draft
riseproject-dev[bot] wants to merge 3 commits into
Draft
riseproject-dev[bot] wants to merge 3 commits into
riseproject-dev[bot] wants to merge 3 commits into
Conversation
Signed-off-by: riseproject-dev[bot] <330740410+riseproject-dev[bot]@users.noreply.github.com>
Contributor
|
luhenry
force-pushed
the
main
branch
3 times, most recently
from
October 1, 2026 15:22
39fb7ba to
a75cf68
Compare
The riscv64 job fails inside the very first `bazel build --nobuild`,
before reaching //xprof/pywrap at all. xprof's WORKSPACE unconditionally
`load()`s `@npm//:repositories.bzl` (wired up by rules_js_dependencies(),
for the frontend's npm/node toolchain), and WORKSPACE files are evaluated
top to bottom regardless of the requested target, so even this
native-extension-only build has to resolve it. That load needs a `yq`
toolchain for the host platform, but aspect_bazel_lib's YQ_PLATFORMS
table (lib/private/yq_toolchain.bzl) has no riscv64 entry, so Bazel
reports an unresolved `@@yq_linux_riscv64` repository ("Cycle in the
workspace file detected ... This could ... mean you have to add the
'@@yq_linux_riscv64' repository").
mikefarah/yq does publish a linux_riscv64 binary, starting at v4.47.1;
aspect_bazel_lib 2.9.1 (the version rules_js 2.1.0 pins) predates that
and never learned about it. Fetch that release locally, add a riscv64
entry to its YQ_PLATFORMS/YQ_VERSIONS tables and bump DEFAULT_YQ_VERSION,
and point Bazel at the patched copy with --override_repository, rather
than touching xprof's own WORKSPACE.
2.23.2 pins a newer @xla (0e4e6b63d1d4) than 2.23.1 (c520e3fb3f00), which in turn pins LLVM ab547095ead5 - a commit past upstream's own fix for the clang-21 SFINAE crash in mlir/lib/IR/BuiltinDialectBytecode.cpp (llvm/llvm-project#188249, fixed by 9722a2ceddb6). getChecked() in StorageUniquerSupport.h already carries the templated Arg1&& workaround at that commit, so 2.23.2 needs no patch at all - unlike 2.23.1, there is no patches/xprof/2.23.2/ directory. The patch-apply loop had no nullglob, so the unmatched .../2.23.2/*.patch glob passed the literal six-character string through to git apply instead of looping zero times: error: can't open patch '.../patches/xprof/2.23.2/*.patch': No such file or directory Add shopt -s nullglob around the loop so a version needing no patch is a clean no-op, the way the loop already intended for the empty case.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automatically generated by the nightly
check_versions.pyrun.xprof v2.23.1 -> v2.23.2
Every
- version:entry added todocs/packages/xprof.yamlis built by this PR's ownbuild-xprof.ymlrun; merging publishes the wheels.