Consider having special debugger pretty printers/handling for Unique/Shared/NonZero

A debugger is particularly useful for diagnosing problems in unsafe code, and these types appear reasonably often there. Currently they're printed in a rather ugly way:

#![feature(unique)]
use std::ptr::Unique;

struct Bar { y: u8 }
struct Foo {
    ptr: Unique<Bar>,
}
fn main() {
    let mut x = Bar { y: 10 };
    unsafe {
        let f = Foo { ptr: Unique::new(&mut x) };

        drop(f);
    }
}

Compiling with rustc -g unique.rs and using rust-gdb unique to break on the drop(f) line allows one to print f:

(gdb) break unique.rs:13
(gdb) r
...
(gdb) p f
$1 = Foo = {ptr = Unique<unique::Bar> = {pointer = NonZero<*const unique::Bar> = {0x7fffffffdef8}, _marker = PhantomData<unique::Bar>}}

Pretty much the only thing that's even slightly interesting there is the 0x7fffffffdef8 and maybe the unique::Bar, the layers of NonZero and PhantomData are just noise. (And even the raw address is pretty useless, and the type is often obvious from context.)

Also, the only way to examine what the pointer points to is to do a pile of field accesses, like:

(gdb) p *f.ptr.pointer.__0
$2 = Bar = {y = 10 '\n'}

In the best case, it'd be great if *f.ptr could work. (Also, f.ptr.pointer.__0[x] being written f.ptr[x], for when the Unique is representing an array.)

(I guess there may be other standard library types to consider in a similar context: making rust-gdb handle them even more nicely.)

1. Filtering out NonZero and Unique in the pretty printers should be doable I think. We already have special handling for Vec<> and String, for example.

   Changing how GDB parses and evaluates expressions is a different thing though. There may be some way to make this work, but doing it cleanly involves going into GDB's rather messy C internals, as far as I know.

   As a side note: It seems that LLDB is starting to support language plugins. A real Rust plugin would make it possible to support all of the above and a lot more :).

   Michael Woerister at 2015-10-27 16:06:28

2. OK, unfortunately this turns out to be way harder to do in GDB than expected. Due to how GDB's pretty printing API is structured, it's not possible filter out intermediate data structure nesting levels (like a NonZero field) without this level still leaving some kind of artifact in the rendered string:

   // This ...
   struct WithNonZero {
       a: NonZero<u32>
   }
   // ... is rendered as this:
   WithNonZero = {a =  = { = 9}}
   

   At least the above is the best thing I managed and I tried various different approaches.

   The only way to get arround this problem is to have pretty printers for every type, even primitive ones. But then one loses the ability to influence how these are printed. E.g. one can't force integers to be printed as hexadecimals anymore, as can be done with print/x. That's pretty bad and personally I think that's too big a tradeoff.

   Michael Woerister at 2015-10-31 15:26:14

3. I looked at this today.

   Upstream output is more or less the same, just more clear that pointer points to a tuple.

   (gdb) p f
   $1 = u::Foo {
     ptr: core::ptr::Unique<u::Bar> {
       pointer: core::nonzero::NonZero<*const u::Bar> (
         0x7fffffffe198
       ),
       _marker: core::marker::PhantomData<u::Bar>
     }
   }
   

   Dereferencing still needs a lot of typing, but it's now Rust syntax at least:

   (gdb) p *f.ptr.pointer.0
   $6 = u::Bar {
     y: 10
   }
   

   For print *f.ptr -- I think making that work in gdb would require gdb knowing that the type implements Deref (currently not in the DWARF). And, then it might also require a non-inlined copy of the appropriate function. Adding the xmethod support would be another approach here.

   Tom Tromey at 2017-05-07 17:29:07

4. Visited during wg-debugging triage. There seems to be two different parts to this issue:

   1. Pretty printers for these types.
   2. Debugger integration with expression evaluation that treats these types more like transparent wrappers.

   The second part is quite a bit more complicated than the first and also relates to ongoing discussions the wg has had with regards to how we want to provider better support for debuggers in general.

   The first part (adding pretty printers) shouldn't be too difficult. We already have NatVis ones here and so we just need to add pretty printers to the appropriate Python scripts here and debuginfo tests to cover them. Tagging as E-medium for the first part.

   Wesley Wiser at 2022-06-20 14:54:45