[PATCH v1] gdb/DAP Introduce new methods to to Pretty Printers

[Simon Farre]

> Matt> FWIW, there has been a bit of spit-balling within the rust community
> Matt> about leveraging Debug trait implementations
> Matt> within pretty printers, where what seemed to me like the obvious way
> Matt> to leverage these was to compile Debug impls to wasm,
> Matt> and write a python wrapper which calls into the wasm.  I haven't
> Matt> thought or looked into it too much to have considered any hurdles of
> Matt> this approach really, but it would be nice if languages with wasm
> Matt> toolchains could define/compile pretty printers in their own language,
> Matt> since often they already exist for the purpose of runtime logging...
> Matt> Seemed worth bringing up if we're spit-balling here too.
>
> Ages ago I looked into this a little, the idea being to compile selected
> functions to Python using the gdb API.  In the end though it seemed too
> hard for the value it would deliver.
>
> Anyway, the wasm approach seems fine -- they solved all the toolchain
> problems, which is nice.  The main issue is that, IIUC, debug traits
> just emit a string representation -- but IMO the debugger really wants a
> more key-value / array-like representation.
>
> This seems like something that could be implemented "on the side", like
> the way that gdb-natvis exists.
>
> Tom
Right, I would agree with Tom here. Having it just represented as a 
string is sort of the "problem" we're in and even though a lot of 
people  (maybe even a majority) still use CLI/TUI, I'm not particularly 
sure demanding new users going forward should be forced to accept such a 
user interface, instead of having it as a choice. A GUI and a CLI/TUI 
have to make substantially different design choices, because a CLI is 
always a REPL, so each individual operation can be somewhat costly, 
because it's going to feel sort of fast for the end user anyway, whereas 
a GUI can see large swathes of the program at every instant - making 
each and every one of those operations build up to a total cost pretty 
quickly.

So, being able to query the types "directly", which means, sub objects, 
ranges etc is something that's valuable. GDB-CLI provides something like 
this with simple C-like types (the foo@10 expression). So, I think that 
excludes the #[derive(DebugWasm)] (ish) approach, unless it fulfills the 
requirements I've talked about here. I do like the idea that it would 
mean not having to write pp's for everything though.

Are there any lessons we can learn from LLDB here? How do they do it?

Then again, what's good about GDB/Python (and therefore the DAP interp) 
is that it allows for some customizability by the DA, so for instance, I 
would drive my DA to enforce the num_children/children_range approach, 
since the point of my DA was performance. So I think, no matter where we 
land, it's probably good if we could let the DA-implementer have room to 
make the tradeoffs it desires. It's also why I think it'd be good if the 
DAP interpreter isn't too reliant on MI because I believe MI was meant 
to solve a different problem (remote, vs a unified GUI & remote-protocol).

Simon