[Debuginfo] improve enum value formatting in LLDB for better readability

[nilptr]

TL;DR: When debugging with CodeLLDB, I noticed enum values were often hard to read because LLDB lists every possible variant, resulting in a verbose and cluttered view, even though only one variant is actually valid. Interestingly, raw enum types display nicely. After some investigation, I found that &enum values get classified as Other, so it falls back to DefaultSyntheticProvider, which causes this verbose output.

What does this PR do?

This PR contains 2 commits:

1. change the enum value formatting from showing 2 separate fields (value for attached data and $discr$ for the discriminator) to a concise <readable variant name>: <attached data> format
2. dereference pointer types in classify_rust_type so that it can return more accurate type for reference type

Self-test proof

Before:

After:

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR was rebased onto a different master commit! Check out the changes with our range-diff.

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 6be749b has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[Walnut356]

@Mark-Simulacrum @nilptr

Just want to chime in and say I think this PR is a regression.

1. It breaks the enum summaries. Non-expanded items no longer display the_a = {$discr$:0}, instead appearing as the_a = {...}. {...} is the fallback value used when the summary provider fails. Even if the summary isn't meant to be {$discr$:0} anymore, it should still be some non-placeholder value

2. I'm not entirely fond of continuing to hide the contents of the value behind another dropdown. I don't really see the benefit compared to just "looking through" the value in the first place. It can also lead to awkwardness with LLDB's repl (e.g. to access a field you now need to include the exact variant name - variable.Variant.field - instead of just a generic variable.value.field or variable.field. For reference, this is how i wrote the MSVC enum provider and I think it would be better to unify in that direction than create more awkward differences between them.

I'm wary of the change to classify_rust_type. Bypassing the distinction between pointers and non-pointers means that the raw pointer SBValue will be passed to the SyntheticProvider and all the synthetics operations will be done on that pointer SBValue. This can cause issues if the synthetic provider makes the assumption that the value isn't a pointer-to-T and operates on it (and on it's SBValue::GetType()) as such. AFAIK all of our synthetics make that assumption, and there's some pretty fragile (but unavoidable) type-based manipulation necessary to make the container types work. I think pointers treat the pointed-to-object's fields as its own fields? But I don't know that that extends to things like template args, nested pointers, and weird edge cases.

It didn't immediately cause problems from what I could tell, but I'd absolutely want more time to test this on MSVC. At the very least, I think a safer course would probably involve creating a PointerSyntheticProvider and delegating to the targeted value's synthetic. That would be a good opportunity to start using the callback-based type matching that's probably a bit more efficient than "every single type gets a synthetic provider" that we're doing right now