Skip to content

lldb-formatters: Use StdSliceSyntheticProvider for &str#124500

Merged
bors merged 1 commit intorust-lang:masterfrom
VladimirMakaev:lldb-str-formatters
May 19, 2024
Merged

lldb-formatters: Use StdSliceSyntheticProvider for &str#124500
bors merged 1 commit intorust-lang:masterfrom
VladimirMakaev:lldb-str-formatters

Conversation

@VladimirMakaev
Copy link
Contributor

&str has associated summary provider which correctly displays string values in debugger, but while working on #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'
  }
}

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants