Repository navigation
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds GDB and LLDB pretty-printers for Changesinplace_vector debugging
Assessment against linked issues
Suggested reviewers: Comment |
| (cuda::std::inplace_vector<int, 4>) | ||
| =============== inplace_vector.empty end =============== | ||
| =============== inplace_vector.partial begin =============== | ||
| (cuda::std::inplace_vector<int, 5>) ([0] = -7, [1] = 0, [2] = 42) |
There was a problem hiding this comment.
We should be printing size and capacity here as well as the elements. The output should look like a std::vector, not like a std::array please.
There was a problem hiding this comment.
Fixed — both printers now show size and capacity. GDB matches libstdc++'s std::vector convention exactly (checked printers.py locally): X of length N, capacity M. LLDB adds a summary provider following the same registration pattern as buffer.py: size=N, capacity=M plus the existing synthetic children. Also rebased onto main to pick up #10563's registration changes. GDB side re-validated end-to-end locally against all 7 scenarios; LLDB golden updated by analogy as before, still unable to execute lldb locally.
a67b543 to
bf9c57c
Compare
bf9c57c to
497f9a1
Compare
Jacobfaib
left a comment
Jacobfaib
left a comment
There was a problem hiding this comment.
LGTM, thanks for the contribution!
|
/ok to test 497f9a1 |
This comment has been minimized.
This comment has been minimized.
Head branch was pushed to by a user without write access
e505e0a to
4cb7fe1
Compare
|
@Jacobfaib the previous run's only failure was an AWS-credentials infra flake in the CTK13.0 MSVC14.29 build job (died in the sccache credential step before compiling anything — confirmed from the logs, unrelated to this PR). I pushed a fresh commit (4cb7fe1) to retrigger — could you /ok to test it when you get a chance? |
|
/ok to test f0eb401 |
Next time please just ping us, we can rerun the individual test case rather then restarting CI all over. |
⏱️ CCCL compile-time benchmark comparison: Public headers compile-time benchResult: 6 regression row(s), 2 improvement row(s) above threshold.
Artifacts: reports and traces Direct file processing
🔴 Direct file processing — Regressions
🟢 Direct file processing — Improvements
|
🥳 CI Workflow Results🟩 Finished in 2h 41m: Pass: 100%/68 | Total: 2d 02h | Max: 2h 10m | Hits: 99%/317355See results here. |
…or (NVIDIA#10564) * [libcudacxx] Add GDB/LLDB pretty-printers for cuda::std::inplace_vector * [libcudacxx] Print inplace_vector length and capacity like std::vector * Retrigger CI after AWS-credentials infra flake in MSVC build job * [libcudacxx] Restore tuple printer registration lost in merge resolution
Description
closes #10096
Adds debugger pretty-printers for
cuda::std::inplace_vector, following the pattern from #10528. Unlikearray, the element count is runtime state, and the container has three compile-time layouts the printers must handle:T: storage is a typed_Tp[_Capacity]array plus__size_;T: storage is a rawunsigned char[Capacity * sizeof(T)]array holding placement-constructed elements.Both printers use one unified read path for the last two layouts — cast the storage address to
T*and index only[0, __size_)— so uninitialized/destroyed slots past the constructed count are never read or displayed. GDB showscuda::std::inplace_vector<int, 5> of size 3 = {…}; LLDB exposes[i]synthetic children.Tests under
libcudacxx/test/debugging/inplace_vector/cover: empty (nonzero capacity), partially filled, full, capacity-0, before/afterpush_back, and nestedinplace_vector<inplace_vector<int, 2>, 3>(whose outer container exercises the raw-storage layout and recursive printing).Testing notes: same situation as #10563 — the GDB printer was validated end-to-end locally (gdb 15.1, host-compiled scenario, harness-generated golden verified on a clean re-run, including raw-memory checks that slots past
__size_are present in storage but excluded from output). I don't have lldb locally; the LLDB provider mirrors the array provider's structure and the gdb logic, andlldb.expectedis written by analogy (all-integer values, so no float-format ambiguity). Happy to fix the lldb golden from the CI diff if it differs.Merge-conflict note: like every PR in this printer series, this touches the shared registration lines (
_PRINTERS/_FORMATTERSingdb/__init__.pyandlldb/__init__.py, and theadd_subdirectorylist intest/debugging/CMakeLists.txt), which will conflict textually with #10534/#10563 — resolution is the union of the added entries; I'll rebase promptly whenever a sibling lands.Checklist