[Proof of Concept ] code coverage for ROCm libraries by jainprad · Pull Request #8656 · ROCm/rocm-libraries

jainprad · 2026-06-22T05:48:34Z

code coverage (duplicate of #8427 for experimentation)

This branch is an exact copy of the head of #8427, opened as a separate PR so
that #8427 can be preserved as a backup while this one is used for further
experimentation.

Adds a TheRock-based code coverage CI flow for hipRAND:

.github/scripts/therock_configure_coverage.py — per-project coverage matrix (hipRAND), pinned to RAND-only build/test
.github/workflows/therock-ci-coverage.yml — build -> test (via therock-test-packages) -> merge/report
.github/workflows/therock-ci.yml, therock-ci-linux.yml, therock-test-packages.yml, therock-test-component.yml — coverage wiring + opt-in coverage flag
projects/hiprand/CMakeLists.txt, projects/hiprand/test/CMakeLists.txt — hipRAND coverage support

Made with Cursor

therock-pr-bot · 2026-06-28T17:30:49Z

❌ PR Check — Action Required

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	—
🔎 pre-commit	❌ Fail	Error: Check concluded with `failure`.
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—

⚠️ 1 policy check(s) failed. Please address the issues above before this PR can be Reviewed.

🚫 Please fix the failed policies

❌ pre-commit

The Not ready to Review label was added to this PR. Once all policies pass, the label is removed automatically.

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

🙋 Wish to Override Policy?

therock-pr-bot · 2026-06-28T17:30:50Z

🚫 Please fix the failed policies before requesting reviews.

The following policy checks failed:

❌ Branch Name

The Not ready to Review label has been added to this PR.
Once all policies pass, the label will be removed automatically.

reboss

Seems like .github/scripts/export_coverage_metadata.py is going to need to change quite a bit to follow the test filter standard, so I left it out of my review. You should be able to make use of the test runners in each of the project folders, whether through extension or adding conditionals in the individual test runners themselves, as we enable coverage for each of the projects

reboss · 2026-06-29T19:41:50Z

+# onto BUILD_CODE_COVERAGE so the header-only library and its tests are instrumented.
+option(HIPCUB_ENABLE_COVERAGE "Enable code coverage (alias for BUILD_CODE_COVERAGE)" OFF)
+if(HIPCUB_ENABLE_COVERAGE)
+  set(BUILD_CODE_COVERAGE ON)


I'd be careful doing this, since other projects having BUILD_CODE_COVERAGE may cause them to instrument their code inadvertently

Addressed — hipCUB coverage is now gated on HIPCUB_ENABLE_COVERAGE directly at the instrumentation site (no shared BUILD_CODE_COVERAGE toggled), so enabling it can't inadvertently instrument other projects. (Header-only coverage is also currently disabled in the flow.)

Looks like these are failing now. You may have missed some places

removed hipcub from this PR. will take care in header only PR.

reboss · 2026-06-29T19:43:58Z

+      rocPRIM:
+        flags: [rocPRIM]
+        target: 80%


This is needed, but is out-of-scope for this PR. Can you please open up a smaller PR with just these changes

Please open another PR with these changes, and link it here, so we don't forget

Split out: the Codecov config + upload tooling now live in a dedicated PR, #9288 (users/jainprad/codecoverage_codecov_tool). This PR no longer changes codecov.yml (it matches develop); the flag additions are tracked in #8955 / #9287.

reboss · 2026-07-06T16:21:23Z

+      - name: Stage coverage objects and llvm tools
+        run: |
+          set -euo pipefail
+          # Use $GITHUB_WORKSPACE (container path) rather than the github.workspace
+          # expression (host path) so the staged dir matches what upload-artifact reads.
+          STAGE="${GITHUB_WORKSPACE}/coverage-objects"
+          DIST="TheRock/build-coverage/dist/rocm"
+          LLVM_BIN="${DIST}/lib/llvm/bin"
+          LIB_NAME="lib$(echo '${{ inputs.cmake_target }}' | tr '[:upper:]' '[:lower:]')"
+          mkdir -p "${STAGE}/lib" "${STAGE}/bin"
+          # Instrumented shared libraries for the target component (used as llvm-cov -object).
+          find "${DIST}" -type f -name "${LIB_NAME}*.so*" -exec cp -av {} "${STAGE}/lib/" \;
+          # Version-matched coverage tooling, so the report job does not depend on the dist.
+          cp -av "${LLVM_BIN}/llvm-profdata" "${STAGE}/bin/"
+          cp -av "${LLVM_BIN}/llvm-cov" "${STAGE}/bin/"
+          # The llvm tools dynamically link libLLVM plus TheRock's bundled sysdeps
+          # (e.g. librocm_sysdeps_z). Stage the whole llvm lib dir and all sysdeps
+          # next to the tools so the report job can run them via LD_LIBRARY_PATH.
+          if [[ -d "${DIST}/lib/llvm/lib" ]]; then
+            find "${DIST}/lib/llvm/lib" -maxdepth 1 -name '*.so*' -exec cp -av {} "${STAGE}/bin/" \;
+          fi
+          # Note: do NOT use -type f here, otherwise the SONAME symlinks (e.g.
+          # librocm_sysdeps_z.so.1 -> librocm_sysdeps_z.so.1.3.2) are skipped and
+          # the loader cannot resolve the dependency.
+          find "${DIST}" -name 'libLLVM.so*' -exec cp -av {} "${STAGE}/bin/" \;
+          find "${DIST}" -name 'librocm_sysdeps_*.so*' -exec cp -av {} "${STAGE}/bin/" \;
+          # Demangler used by llvm-cov show for readable HTML.
+          cp -av "${LLVM_BIN}/llvm-cxxfilt" "${STAGE}/bin/" 2>/dev/null || true
+          echo "Staged coverage objects:"
+          ls -lR "${STAGE}"
+          echo "llvm-profdata dependencies (in build env):"
+          ldd "${STAGE}/bin/llvm-profdata" || true


What is the need for all of this?

The report job runs llvm-cov/llvm-profdata that must be raw-profile-format compatible with the compiler that instrumented the libraries, so we stage those exact tools (plus libLLVM.so* and the rocm_sysdeps libs they load) from the coverage build's own dist. That's the strictest version-match guarantee. It can be replaced by fetching the same amd-llvm artifact from this run instead — see my detailed reply on the fetch_artifact_args thread below.

this is incredibly dense and hard to read. could we write this in a python script that handles this?

also, your reply should be included in the code itself, so an engineer can view it and understand why it is needed

We don't need a python script at all. We just need to use fetch_artifacts.py to get llvm-* tools, and then the .so file will be on the test node already, so we don't need to upload it here as well

reboss · 2026-07-06T16:25:06Z

+      - name: Upload coverage objects and llvm tools
+        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
+        with:
+          name: coverage-objects-${{ inputs.project_name }}-${{ inputs.amdgpu_families }}
+          # Relative path resolves against the container workspace, matching the staging step.
+          path: coverage-objects
+          if-no-files-found: error
+          retention-days: 7


This might require some more discussion/design considerations, if we need to upload the llvm binaries to the test node

Dug into this. The tools/libLLVM don't go to the test node (the test job only emits profraw) — they're needed in the report job. Rather than uploading them, the report job can fetch the version-matched amd-llvm artifact from this same run. Full mechanism, exact fetch_artifacts.py invocation, and the tradeoff are in my reply on the fetch_artifact_args thread below.

we currently use AWS S3 to store our artifacts. we should convert to that, so if an engineer wants to download artifacts locally, they can use our scripts to do so rather than introducing new storage which will result in more retrieval scripts

this will take a bit more discussion too, i agree

reboss · 2026-07-06T16:39:57Z

    name: Test (${{ inputs.amdgpu_families }})
    needs: [therock-build-linux]
-    # TODO(TheRock#3288): Re-enable gfx950-dcgpu runners once we get more capacity
-    if: ${{ inputs.amdgpu_families != 'gfx950-dcgpu' }}


Not sure why this is removed. Might have been me that removed it by accident. Please add back

Done (b8ecfdd) — the if: ${{ inputs.amdgpu_families != 'gfx950-dcgpu' }} guard is restored in therock-ci-linux.yml.

this is not done. please restore it

therock-ci-linux.yml is not part of this PR code.

This needs to be reverted. It is still present from my work. I'm not sure why I disabled it, but it must be reverted before merge

codecov-commenter · 2026-07-09T15:02:19Z

Codecov Report

✅ All modified and coverable lines are covered by tests.

Additional details and impacted files

@@             Coverage Diff              @@
##           develop    #8656       +/-   ##
============================================
- Coverage    69.35%   63.43%    -5.92%     
============================================
  Files         2777     1105     -1672     
  Lines       457902   137802   -320100     
  Branches     67514    16879    -50635     
============================================
- Hits        317548    87405   -230143     
+ Misses      117221    46045    -71176     
+ Partials     23133     4352    -18781

Flag	Coverage Δ
TensileLite-CPP	`?`
TensileLite-Unit	`?`
hipBLAS	`?`
hipBLASLt	`?`
hipCUB	`83.26% <ø> (+0.58%)`	⬆️
hipDNN	`?`
hipFFT	`?`
hipRAND	`?`
hipSOLVER	`?`
hipSPARSE	`?`
rocBLAS	`48.26% <ø> (ø)`
rocFFT	`52.06% <ø> (+4.42%)`	⬆️
rocRAND	`57.05% <ø> (ø)`
rocSOLVER	`?`
rocSPARSE	`?`
rocThrust	`91.35% <ø> (-0.25%)`	⬇️
see 2101 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

reboss · 2026-07-10T14:24:33Z

-    target_link_libraries(${BENCHMARK_TARGET} PRIVATE amd_smi)
+    # primbench uses AMD SMI for optional GPU monitoring. Treat it as a soft
+    # dependency: enable monitoring only when the amd-smi dev header is
+    # available, otherwise build the benchmark without monitoring instead of
+    # failing to compile. This keeps narrowed component builds that do not stage
+    # the amd-smi dev headers (e.g. code-coverage builds) working.
+    find_path(ROCRAND_AMDSMI_INCLUDE_DIR amd_smi/amdsmi.h HINTS ENV ROCM_PATH PATH_SUFFIXES include)
+    if(ROCRAND_AMDSMI_INCLUDE_DIR)
+      target_include_directories(${BENCHMARK_TARGET} PRIVATE ${ROCRAND_AMDSMI_INCLUDE_DIR})
+      target_link_libraries(${BENCHMARK_TARGET} PRIVATE amd_smi)
+    else()
+      message(STATUS "AMD SMI headers not found; building ${BENCHMARK_TARGET} without primbench GPU monitoring")
+      target_compile_definitions(${BENCHMARK_TARGET} PRIVATE PRIMBENCH_NO_MONITORING)
+    endif()


This seems out of scope for this PR, and has the potential to affect non-code-coverage builds moving forward. If you can go without it, I'd remove it. Otherwise, you may need to seek review from the rocRAND team. Tagging @stanleytsang-amd for visibility.

Done in 1ec0936 - reverted projects/rocrand/benchmark/CMakeLists.txt to develop, so the AMD-SMI soft-dependency change is no longer part of this PR. Heads-up: this change is what let the narrowed RAND-only coverage build compile the rocRAND benchmark (which links amd_smi); with it removed, if the coverage build still builds the benchmark it may fail to compile again. If needed I can exclude the benchmark from the coverage build, or this can be re-introduced via a rocRAND-team-reviewed PR (cc @stanleytsang-amd).

Re-applied in 585f39b. Removing this broke the RAND-group coverage builds: hipRAND, rocRAND and rocFFT all build the RAND group, and shared/primbench/primbench.hpp includes + links amd_smi unconditionally, but the narrowed coverage build stages no amd-smi dev headers -> fatal error: 'amd_smi/amdsmi.h' file not found -> no profraw, no report for all three.

The benchmark can't be disabled from rocm-libraries either: TheRock pins -DBUILD_BENCHMARK=${THEROCK_BUILD_TESTING} for rocRAND (math-libs/CMakeLists.txt), and coverage needs THEROCK_BUILD_TESTING=ON to build the tests.

The soft dependency only changes behavior when the amd-smi header is absent (narrowed/coverage builds); normal builds have the header, so they link amd_smi + enable monitoring exactly as before -> no impact on non-coverage builds. Happy to move it to a rocRAND-team-reviewed PR if you'd prefer, but it's required for the coverage build to compile.

I saw some issue while removing it. keeping it for end. I will revisit it.

This PR is scoped to the header-only libraries (rocPRIM / hipCUB / rocThrust). Restore the shared-object components' CMakeLists (hipRAND / rocRAND / rocFFT / rocBLAS) to develop verbatim so they are not part of this PR - they are covered in the shared-object PR (#8656). Co-authored-by: Cursor <cursoragent@cursor.com>

…build) The hipRAND coverage build compiles rocRAND (a dependency), including its benchmarks. Reverting rocrand/benchmark/CMakeLists.txt to develop dropped the "AMD SMI soft dependency" fix, so the narrowed coverage build (no amd-smi dev headers) failed with: primbench.hpp: fatal error: 'amd_smi/amdsmi.h' file not found. Restore that one file (it is a build prerequisite for coverage builds, not a rocRAND coverage feature). All other rocBLAS/rocFFT/rocRAND changes remain reverted; the PR stays hipRAND-only for coverage. Co-authored-by: Cursor <cursoragent@cursor.com>

…r set -e) The Test step derived the ctest dir by grepping the component's test_script for --test-dir, but after the develop merge test_script is now 'python .../test_runner.py' (no --test-dir). grep found nothing and exited 1, which under `set -e -o pipefail` killed the coverage Test step before coverage_runner.py ran (build passed, test shard failed instantly). Derive the ctest dir by finding build/bin/<Component> case-insensitively (hipRAND vs hiprand) and guard the command substitutions with `|| true`. Co-authored-by: Cursor <cursoragent@cursor.com>

…build) The coverage build produced a non-instrumented libhiprand.so (0 __llvm_profile symbols) even though -fprofile-instr-generate was in the compile command and the sub-project was configured with coverage. Root cause: ccache (direct mode, 96% hit rate) does not include -fprofile-instr-generate in its hash, so the coverage compile hit a cached NON-coverage hiprand.cpp object. Add a coverage-only compile define (HIPRAND_COVERAGE_INSTRUMENTED=1) so ccache keys the coverage build separately and recompiles hiprand.cpp fresh (instrumented). This busts only hipRAND's cache entry -- LLVM/HIP/deps still hit ccache, avoiding a multi-hour full rebuild (and avoids the shared-cache pollution risk of CCACHE_RECACHE). Co-authored-by: Cursor <cursoragent@cursor.com>

Co-authored-by: Jobbins <mulvanyrobbinsj@gmail.com>

…ck@enable-codecov) Point the coverage build's TheRock checkout back at ROCm/TheRock at the pinned inputs.therock_ref instead of the personal reboss/TheRock@enable-codecov branch. Co-authored-by: Cursor <cursoragent@cursor.com>

…mary Add therock-ci-coverage back to the therock_ci_summary needs list so coverage is part of the CI gate again. Coverage now runs green (build instruments hipRAND; coverage_runner.py skips gracefully when no profraw is produced), so it no longer needs to be non-blocking. Co-authored-by: Cursor <cursoragent@cursor.com>

Coverage is now a gating job, so an empty profraw result must surface instead of passing as a no-op. Replace the graceful "no .profraw -> skip/return" with a logged error + non-zero exit, so a non-instrumented library / no coverage data fails the coverage job (red) rather than going green. Co-authored-by: Cursor <cursoragent@cursor.com>

…rtifact layer) TheRock ships a non-instrumented rand_lib artifact, so the test job downloads a libhiprand.so with 0 __llvm_profile symbols and produces no profraw. Work around it: - Build job: upload the instrumented TheRock/build-coverage/dist/rocm/lib/libhiprand.so* as artifact coverage-instrumented-lib-<amdgpu_families>. - Test job: download it and overwrite ./build/lib/libhiprand.so.1.1 (the real file the tests load via RPATH) before running the tests, so ctest exercises the instrumented library and emits profraw. Keyed by amdgpu_families so each GPU family gets its own arch-specific instrumented lib. Co-authored-by: Cursor <cursoragent@cursor.com>

…test node The swap-in now produces real coverage, but llvm-cov show emitted "error: .../hiprand.cpp: No such file" because the build bakes the source path at <workspace>/projects/... (rocm-libraries at the build workspace root) while the test node checks rocm-libraries out under <workspace>/rocm-libraries. Add a --path-equivalence option to coverage_runner.py (applied to llvm-cov report/show/export) and pass -path-equivalence=<ws>,<ws>/rocm-libraries from the test workflow so sources resolve and the HTML report annotates them. Co-authored-by: Cursor <cursoragent@cursor.com>

…tifact After coverage_runner.py generates the report, upload ${GITHUB_WORKSPACE}/coverage-report (HTML, code_cov_<proj>.report, coverage.info, <proj>.profdata) as artifact coverage-report-<project>-<amdgpu_family>-shard<N> so it can be downloaded from the run. Co-authored-by: Cursor <cursoragent@cursor.com>

malcolmroberts · 2026-07-22T16:30:19Z

Closing because there are 10 of these open.

ScottTodd

Drive-by comments since this filtered down to some PRs in TheRock (ROCm/TheRock#3761)

There are some pretty large architectural issues with the direction taken here. I also see 170+ comments and 130+ commits already on this PR that has been open for over 1 month.

Please provide a link to the design proposal for this work. At this level of cross-project complexity, this should have started from a plan that gets review/approval before jumping to a pull request with code. If there have been design discussions offline, sharing the meeting notes could help too.

ScottTodd · 2026-07-22T17:52:33Z

Why is this a separate workflow? I'd prefer to integrate coverage directly into existing build and test jobs if possible.

Do you have a design/plan written down somewhere that we could review?

ScottTodd · 2026-07-22T17:59:14Z

+      project_name:
+        type: string


One workflow job running cmake --build TheRock/build-coverage --target therock-artifacts therock-dist per project isn't going to be viable for a few reasons:

The artifacts built by each job are overlapping, resulting in excessive CPU builder usage

Those jobs then upload those overlapping artifacts to S3 and there will likely be conflicts (between the "coverage"/"non-coverage" CI runs and between each instance of this where the base artifacts are rebuilt for each project). Those conflicts can result in downstream test and packaging workflows using a nondeterministic set of files based on which jobs complete in what order

applying a different namespace for each job's artifacts/logs/etc. could help here but we really shouldn't be rebuilding unless actually necessary

See example logs on this PR

https://github.com/ROCm/rocm-libraries/actions/runs/29938737888/job/88987241643?pr=8656

https://github.com/ROCm/rocm-libraries/actions/runs/29938737888/job/88987241685?pr=8656

Multi-gpu (and multi-process) libraries need to have code coverage executed on those configurations as well, with the results used to give an overall code coverage report. Is there any plan on how to do this? This had been discussed in math-ci, but therock-ci may be unaware of these efforts.

hipRAND coverage instruments a real shared library (libhiprand.so), so the header-only test-binary machinery and a few other paths were never exercised. Remove them so there is a single source of truth: - coverage_runner.py: fix stale docstring (it IS wired into CI via therock-test-component.yml); resolve shared-library objects only; drop the unused --skip-tests and --profraw-dir arguments. - export_coverage_metadata.py: drop test-binary discovery/staging (_looks_like_executable, find_test_binaries, --cmake-target/--stage-dir) and the legacy combined-file layout (resolve_project_key); libraries-only metadata. - therock_configure_coverage.py / therock-ci.yml / therock-ci-coverage.yml: remove the coverage_config input that was threaded through but never read. No functional change to the hipRAND coverage flow. Co-authored-by: Cursor <cursoragent@cursor.com>

malcolmroberts

If this is code coverage for hiprand, it should not do code coverage for rocfft.

Ports the code coverage changes from PR #8656 (jainprad/codecoverage_lib_v2): - Coverage CI workflows and runner/configuration scripts - CMake coverage wiring for hiprand, rocfft, rocrand Co-authored-by: Cursor <cursoragent@cursor.com>

therock-pr-bot · 2026-07-28T06:37:34Z

Pre-commit check failed

⛔ pre-commit failed

Please run locally:

python -m pip install pre-commit
pre-commit install
pre-commit run --all-files --show-diff-on-failure

This repo uses .pre-commit-config.yaml.

malcolmroberts · 2026-09-03T16:06:18Z

This seem stale, so I'm closing. Feel free to re-open.

jainprad requested review from a team as code owners June 22, 2026 05:48

github-actions Bot added project: hiprand github actions labels Jun 22, 2026

assistant-librarian Bot added the organization: ROCm label Jun 22, 2026

github-actions Bot added the project: rocrand label Jun 25, 2026

jainprad requested a review from a team as a code owner June 25, 2026 11:00

github-actions Bot added the project: rocfft label Jun 25, 2026

jainprad requested review from a team as code owners June 28, 2026 16:53

github-actions Bot added project: rocblas project: rocsparse labels Jun 28, 2026

jainprad changed the title ~~Jainprad/codecoverage lib (v2 experiment)~~ ci: add code coverage for ROCm libraries (v2 experiment) Jun 28, 2026

github-actions Bot added project: hipcub project: rocprim project: rocthrust labels Jun 29, 2026

reboss requested changes Jun 29, 2026

View reviewed changes

kliegeois removed the project: rocsparse label Jun 30, 2026

This was referenced Jun 30, 2026

codecov: add rocPRIM coverage flag #8955

Closed

rocthrust: fall back to bundled SQLite when system package is unsuitable #8956

Closed

reboss requested changes Jul 6, 2026

View reviewed changes

This was referenced Jul 8, 2026

ci: code coverage for ROCm libraries (backup of #8656 @ a13f790f) #9199

Closed

ci: code coverage for ROCm libraries (backup of #9199 @ b0a66ab) #9216

Closed

reboss requested changes Jul 10, 2026

View reviewed changes

jainprad mentioned this pull request Jul 10, 2026

ci: add code coverage for header-only ROCm libraries (rocPRIM/hipCUB/rocThrust) #9287

Closed

3 tasks

jainprad and others added 7 commits July 21, 2026 16:29

Apply suggestion from @reboss

4b3bbc7

Co-authored-by: Jobbins <mulvanyrobbinsj@gmail.com>

jainprad force-pushed the jainprad/codecoverage_lib_v2 branch from 43610f5 to abf3462 Compare July 21, 2026 17:22

reboss mentioned this pull request Jul 21, 2026

feat: add a passthrough for PROJECT_ENABLE_COVERAGE flag ROCm/TheRock#3761

Closed

1 task

jainprad and others added 4 commits July 22, 2026 05:36

Merge branch 'develop' into jainprad/codecoverage_lib_v2

9ea1602

malcolmroberts closed this Jul 22, 2026

jainprad reopened this Jul 22, 2026

ScottTodd reviewed Jul 22, 2026

View reviewed changes

jainprad changed the title ~~code coverage for ROCm libraries~~ [POC] code coverage for ROCm libraries Jul 23, 2026

jainprad changed the title ~~[POC] code coverage for ROCm libraries~~ [Proof of Concept ] code coverage for ROCm libraries Jul 23, 2026

malcolmroberts requested changes Jul 23, 2026

View reviewed changes

reboss marked this pull request as draft July 23, 2026 21:32

jainprad added 2 commits July 27, 2026 04:56

Merge branch 'develop' into jainprad/codecoverage_lib_v2

62bf8d1

Merge branch 'develop' into jainprad/codecoverage_lib_v2

8687fa2

Merge branch 'develop' into jainprad/codecoverage_lib_v2

6cc4ff4

malcolmroberts closed this Sep 3, 2026

tony-davis mentioned this pull request Oct 2, 2026

Update TheRock reference to (c9bde5b) #12826

Merged

Conversation

jainprad commented Jun 22, 2026

Uh oh!

therock-pr-bot Bot commented Jun 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

❌ PR Check — Action Required

Uh oh!

therock-pr-bot Bot commented Jun 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

reboss left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

codecov-commenter commented Jul 9, 2026 • edited by codecov Bot Loading Uh oh! There was an error while loading. Please reload this page.

therock-pr-bot Bot commented Jun 28, 2026 •

edited

Loading

therock-pr-bot Bot commented Jun 28, 2026 •

edited

Loading

codecov-commenter commented Jul 9, 2026 •

edited by codecov Bot

Loading