lldb-formatters: Use StdSliceSyntheticProvider for &str

[VladimirMakaev]

&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'
  }
}

[rustbot]

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 (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 3e82257 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[matthiaskrgr]

@bors r-
#124697 (comment)

[VladimirMakaev]

Updated debuginfo/empty-string.rs test to match new output

@rustbot review

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 5b2be36 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

⌛ Testing commit 5b2be36 with merge e76034c...

[bors]

💔 Test failed - checks-actions

[VladimirMakaev]

I build GDB 11.2 version locally and tests were still passing. However when I added:

#![feature(omit_gdb_pretty_printer_section)]
#![omit_gdb_pretty_printer_section]

I reproed the failures on CI and updated the tests

Hopefully the CI will pass now

@bors review

[VladimirMakaev]

Another CI job failed, and apparently there is a diff in how the pointer part of the string is displayed in GDB 11.2 (which failed before during land) and 14.0 (which failed now on PR). I've set requirement on GDB 14.0+ for this test. My change is really about LLDB but thought having extra tests for GDB wouldn't hurt.

[VladimirMakaev]

@bors review

[VladimirMakaev]

@bors review

[VladimirMakaev]

@rustbot review

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 330ce83 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

⌛ Testing commit 330ce83 with merge 6579ed8...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 6579ed8 to master...

[rust-timer]

Finished benchmarking commit (6579ed8): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -3.6%, secondary 4.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.0%	[4.0%, 4.0%]	1
Improvements ✅ (primary)	-3.6%	[-3.6%, -3.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.6%	[-3.6%, -3.6%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 671.223s -> 670.24s (-0.15%)
Artifact size: 316.05 MiB -> 316.18 MiB (0.04%)