Improve usability for debugging Rust

[gamedev-pnc]

Hi! First of all, thanks to all contributors for creating CodeLLDB. I use CodeLLDB (1.10.0) to debug Rust (1.79.0) in VSCode (1.85.1). Unfortunately, it's uninformative now:

1. [Bug] instead of values, it shows "read memory from ... failed" (happens very often, unpredictably; reason unknown).

---

2. [Usability] Is it possible to (optionally) shorten type names? As you can see, long (and typical for Rust) prefix "union enum2$<code::result::Result<alloc::boxed::Box<dyn$" has zero of valuable information. I have big monitor, and still it's not enough.It requires making Debug Panel very wide for every debug session, which is inconvenient.

---

3.1. [Usability] Which value does enum have? Would be nice to highlight current variant and add some preview for it (variant names, at least).
3.2. When enum has many variants, scrolling (and maybe expanding) all of them is not very convenient.

---

4. [Usability] Which type Any points to? Is it possible to show this information?

---

5. [Usability] Breakpoints do not work in the inlined functions, which is understandable. "#[derive(never)]" helps. And "[profile.dev] opt-level = 0" helps. Anyway, if CodeLLDB can control it, would be convenient to have an option "forcefully avoid any inlining". Otherwise it can confuse new Rust developers.

---

6. [Usability] Would be convenient to have value preview, when type implements trait Debug/Display. It can be a security/performance concern; if that's the case, then this feature can be optional, but still would be great to have it.

I'm sorry, but I feel that these issues make CodeLLDB unusable and uninformative tool for debugging Rust applications... I hope, at least part of them can be solved. Perhaps there are already settings that can fix any of the above? Or are these features already being developed? Thanks in advance.

[jerrywrice]

I agree, and viewing the runtime content of an enum struct with vector values is awkward. Here's an example
with a variable of E5Item::Binary(vec![94u8,55u8,66u8]) where E5Item is defined as

pub enum E5Item { LIST(Vec), BINARY(Vec), BOOLEAN(Vec), ASCII(Vec), JIS8(Vec),
TWOBYTECHAR(Vec), I64INTEGER(Vec), I8INTEGER(Vec), I16INTEGER(Vec),
I32INTEGER(Vec), F64FLOAT(Vec), F32FLOAT(Vec), U64INTEGER(Vec),
U8INTEGER(Vec), U16INTEGER(Vec), U32INTEGER(Vec), UNKNOWN, }

here's a runtime display screen-shot (note the two red-circled ovals show the three bytes of data (94u8,55u8,66u8), which are shown as ASCII characters on the left panel, and as hex bytes in the right memory view. The right memory view is practically useless, since it seems to be a dump of the heap based on the fat pointer - so it's impossible to find the actual vector data. I only identified it by visually searching for the expected three bytes. I do thank the team for all the hard and great work you've put into this!