Implement lldb formatter for "clang encoded" enums (LLDB 18.1+) #124458
Conversation
This file contains 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
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
rustbot
added
the
S-waiting-on-review
src/etc/rust-lldb
Outdated
| @@ -10,7 +10,7 @@ host=$(rustc -vV | sed -n -e 's/^host: //p') | |||
| RUSTC_SYSROOT=$(rustc --print sysroot) | |||
| RUST_LLDB="$RUSTC_SYSROOT/lib/rustlib/$host/bin/lldb" | |||
|
|
|||
| lldb="lldb" | |||
| lldb=lldb | |||
There was a problem hiding this comment.
Can you say more about this change? I don't understand why it is needed...
There was a problem hiding this comment.
Maybe just leftover from the last two commits? We should squash regardless, but would be good to avoid spurious changes.
r=me with this dropped + commits squashed.
There was a problem hiding this comment.
I'll squash and clean up thought you'd squash on merge anyway. But I messed up with some local testing and then tried to cleanup
There was a problem hiding this comment.
All squashed now
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
May 4, 2024
…, r=Mark-Simulacrum lldb-formatters: Use StdSliceSyntheticProvider for &str &str has associated summary provider which correctly displays string values in debugger, but while working on rust-lang#124458 I've noticed that a &str inside an enum displays a blob of memory until a 0 is reached (as a c-string) which makes a very bizarre experience when debugging However there is already StdSliceSyntheticProvider which we use for other slices. This PR enables the same synthetic provider to be used for &str, however the summary provider is still fixed to return the string value I've added a test `debuginfo/strings-and-strs.rs` which prior to this PR would output the following in LLDB: ``` * thread #1, name = 'a', stop reason = breakpoint 1.1 frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5 44 let plain_str = "Hello"; 45 let str_in_struct = Foo { inner: "Hello" }; 46 let str_in_tuple = ("Hello", "World"); -> 47 zzz(); // #break 48 } 49 50 fn zzz() { (lldb) frame var (alloc::string::String) plain_string = "Hello" { vec = size=5 { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } (&str) plain_str = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } (strings_and_strs::Foo) str_in_struct = { inner = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } } ((&str, &str)) str_in_tuple = { 0 = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } 1 = "World" { data_ptr = 0x0000555555557268 "World\U00000001gdb_load_rust_pretty_printers.py" length = 5 } } ``` After this PR it would look the following way: ``` * thread #1, name = 'a', stop reason = breakpoint 1.1 frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5 44 let plain_str = "Hello"; 45 let str_in_struct = Foo { inner: "Hello" }; 46 let str_in_tuple = ("Hello", "World"); -> 47 zzz(); // #break 48 } 49 50 fn zzz() { (lldb) frame var (alloc::string::String) plain_string = "Hello" { vec = size=5 { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } (&str) plain_str = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } (strings_and_strs::Foo) str_in_struct = { inner = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } ((&str, &str)) str_in_tuple = { 0 = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } 1 = "World" { [0] = 'W' [1] = 'o' [2] = 'r' [3] = 'l' [4] = 'd' } } ```
Summary: I landed a fix last year to enable `DW_TAG_variant_part` encoding in LLDBs (https://reviews.llvm.org/D149213). This PR is a corresponding fix in synthetic formatters to decode that information. This is in no way perfect implementation but at least it improves the status quo. But most types of enums will be visible and debuggable in some way. I've also updated most of the existing tests that touch enums and re-enabled test cases based on LLDB for enums. Test Plan: ran tests `./x test tests/debuginfo/`. Also tested manually in LLDB CLI and LLDB VSCode Other Thoughs A better approach would probably be adopting [formatters from codelldb](https://github.com/vadimcn/codelldb/blob/master/formatters/rust.py). There is some neat hack that hooks up summary provider via synthetic provider which can ultimately fix more display issues for Rust types and enums too. But getting it to work well might take more time that I have right now.
VladimirMakaev
force-pushed
the
lldb-enum-formatter
branch
from
530c5b8
to
43e6600
Compare
dtolnay
approved these changes
May 4, 2024
|
@bors r=Mark-Simulacrum |
bors
added
S-waiting-on-bors
fmease
added a commit
to fmease/rust
that referenced
this pull request
May 5, 2024
…, r=Mark-Simulacrum Implement lldb formattter for "clang encoded" enums (LLDB 18.1+) ## Summary: fixes rust-lang#79530 I landed a fix last year to enable `DW_TAG_variant_part` encoding in LLDBs (https://reviews.llvm.org/D149213). This PR is a corresponding fix in synthetic formatters to decode that information. This is in no way perfect implementation but at least it improves the status quo. But most types of enums will be visible and debuggable in some way. I've also updated most of the existing tests that touch enums and re-enabled test cases based on LLDB for enums. ## Test Plan: ran tests `./x test tests/debuginfo/`. Also tested manually in LLDB CLI and LLDB VSCode ## Other Thoughs: A better approach would probably be adopting [formatters from codelldb](https://github.com/vadimcn/codelldb/blob/master/formatters/rust.py). There is some neat hack that hooks up summary provider via synthetic provider which can ultimately fix more display issues for Rust types and enums too. But getting it to work well might take more time that I have right now.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 5, 2024
Rollup of 7 pull requests Successful merges: - rust-lang#122253 (Support Result<T, E> across FFI when niche optimization can be used) - rust-lang#123892 (Document That `f16` And `f128` Hardware Support is Limited) - rust-lang#124458 (Implement lldb formattter for "clang encoded" enums (LLDB 18.1+)) - rust-lang#124459 (Stabilize exclusive_range_pattern) - rust-lang#124711 (Migrate `run-make/doctests-runtool` to rmake) - rust-lang#124725 (Meta: Enable the brand new triagebot transfer command) - rust-lang#124727 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 5, 2024
Rollup of 7 pull requests Successful merges: - rust-lang#122253 (Support Result<T, E> across FFI when niche optimization can be used) - rust-lang#123892 (Document That `f16` And `f128` Hardware Support is Limited) - rust-lang#124458 (Implement lldb formattter for "clang encoded" enums (LLDB 18.1+)) - rust-lang#124459 (Stabilize exclusive_range_pattern) - rust-lang#124711 (Migrate `run-make/doctests-runtool` to rmake) - rust-lang#124725 (Meta: Enable the brand new triagebot transfer command) - rust-lang#124727 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
|
☀️ Test successful - checks-actions |
|
This PR has been merged by accident, without the full test suite being run. It was my fault (#124631 got merged and it broke our CI). @VladimirMakaev Could you please create a new PR with your branch against the latest version of |
|
New PR, from the same branch: #124745 |
fmease
added a commit
to fmease/rust
that referenced
this pull request
May 5, 2024
…, r=Mark-Simulacrum Implement lldb formattter for "clang encoded" enums (LLDB 18.1+) (v2) This PR is identical to rust-lang#124458, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F). Original PR description: --- ## Summary: fixes rust-lang#79530 I landed a fix last year to enable `DW_TAG_variant_part` encoding in LLDBs (https://reviews.llvm.org/D149213). This PR is a corresponding fix in synthetic formatters to decode that information. This is in no way perfect implementation but at least it improves the status quo. But most types of enums will be visible and debuggable in some way. I've also updated most of the existing tests that touch enums and re-enabled test cases based on LLDB for enums. ## Test Plan: ran tests `./x test tests/debuginfo/`. Also tested manually in LLDB CLI and LLDB VSCode ## Other Thoughs: A better approach would probably be adopting [formatters from codelldb](https://github.com/vadimcn/codelldb/blob/master/formatters/rust.py). There is some neat hack that hooks up summary provider via synthetic provider which can ultimately fix more display issues for Rust types and enums too. But getting it to work well might take more time that I have right now.
dtolnay
changed the title
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 7, 2024
…r=dtolnay Implement lldb formatter for "clang encoded" enums (LLDB 18.1+) (V3) This is a redo of PR (rust-lang#124458) which was approved previously but force-pushed out. Then a V2 (rust-lang#124745) failed `debuginfo\msvc-pretty-enums.rs` test during merge. I've fixed the test and checked it to pass on Windows with `.\x.ps1 test .\tests\debuginfo\msvc-pretty-enums.rs` Below is the original summary: ## Summary: fixes rust-lang#79530 I landed a fix last year to enable `DW_TAG_variant_part` encoding in LLDBs (https://reviews.llvm.org/D149213). This PR is a corresponding fix in synthetic formatters to decode that information. This is in no way perfect implementation but at least it improves the status quo. But most types of enums will be visible and debuggable in some way. I've also updated most of the existing tests that touch enums and re-enabled test cases based on LLDB for enums. ## Test Plan: ran tests `./x test tests/debuginfo/`. Also tested manually in LLDB CLI and LLDB VSCode ## Other Thoughs: A better approach would probably be adopting [formatters from codelldb](https://github.com/vadimcn/codelldb/blob/master/formatters/rust.py). There is some neat hack that hooks up summary provider via synthetic provider which can ultimately fix more display issues for Rust types and enums too. But getting it to work well might take more time that I have right now.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 11, 2024
…r=Mark-Simulacrum lldb-formatters: Use StdSliceSyntheticProvider for &str &str has associated summary provider which correctly displays string values in debugger, but while working on rust-lang#124458 I've noticed that a &str inside an enum displays a blob of memory until a 0 is reached (as a c-string) which makes a very bizarre experience when debugging However there is already StdSliceSyntheticProvider which we use for other slices. This PR enables the same synthetic provider to be used for &str, however the summary provider is still fixed to return the string value I've added a test `debuginfo/strings-and-strs.rs` which prior to this PR would output the following in LLDB: ``` * thread #1, name = 'a', stop reason = breakpoint 1.1 frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5 44 let plain_str = "Hello"; 45 let str_in_struct = Foo { inner: "Hello" }; 46 let str_in_tuple = ("Hello", "World"); -> 47 zzz(); // #break 48 } 49 50 fn zzz() { (lldb) frame var (alloc::string::String) plain_string = "Hello" { vec = size=5 { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } (&str) plain_str = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } (strings_and_strs::Foo) str_in_struct = { inner = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } } ((&str, &str)) str_in_tuple = { 0 = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } 1 = "World" { data_ptr = 0x0000555555557268 "World\U00000001gdb_load_rust_pretty_printers.py" length = 5 } } ``` After this PR it would look the following way: ``` * thread #1, name = 'a', stop reason = breakpoint 1.1 frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5 44 let plain_str = "Hello"; 45 let str_in_struct = Foo { inner: "Hello" }; 46 let str_in_tuple = ("Hello", "World"); -> 47 zzz(); // #break 48 } 49 50 fn zzz() { (lldb) frame var (alloc::string::String) plain_string = "Hello" { vec = size=5 { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } (&str) plain_str = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } (strings_and_strs::Foo) str_in_struct = { inner = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } ((&str, &str)) str_in_tuple = { 0 = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } 1 = "World" { [0] = 'W' [1] = 'o' [2] = 'r' [3] = 'l' [4] = 'd' } } ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary:
fixes #79530
I landed a fix last year to enable
DW_TAG_variant_partencoding in LLDBs (https://reviews.llvm.org/D149213). This PR is a corresponding fix in synthetic formatters to decode that information.This is in no way perfect implementation but at least it improves the status quo. But most types of enums will be visible and debuggable in some way.
I've also updated most of the existing tests that touch enums and re-enabled test cases based on LLDB for enums.
Test Plan:
ran tests
./x test tests/debuginfo/. Also tested manually in LLDB CLI and LLDB VSCodeOther Thoughs:
A better approach would probably be adopting formatters from codelldb. There is some neat hack that hooks up summary provider via synthetic provider which can ultimately fix more display issues for Rust types and enums too. But getting it to work well might take more time that I have right now.