[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

[nilptr]

Thanks @Walnut356 for the detailed feedback, and sorry for causing this regression. @Mark-Simulacrum I think it would be the best to revert my changes first to avoid impact more users.

[nilptr]

My intention was to address 2 issues that has been bothering me:

1. noisy display of enum references;
2. I have to mentally match the $discr$ value with the actual variant, which can be tedious when there are many variants.

Apparently, my approach was not well thought out. I should have marked it as a draft in the first place. sorry again for this.

I believe @Walnut356 has proposed a better solution for issue 1.
For issue 2, I just need a quick way to know which variant it is — whether I access it as enum_var.Variant.field or enum_var.value.field doesn't make much difference to me.
The <variant name>: <attached data> format was inspired by the Swift debugger ¹, and the MSVCEnumSyntheticProvider design also looks good to me.

Footnotes

1. Swift debugger screenshot ↩

[Walnut356]

For sure, enums have consistently been a pain point for both msvc and gnu.

This pr should fix the pointer-to-enum issue, as it necessitates adding the pointer synthetic i mentioned in my prior comment. Eventually that might not be necessary either, but i have to do some digging to see if it's a CodeLLDB problem or not.

Improving the variant output should be pretty straightforward, though in the meantime there's a vscode setting that displays the type names of variables in the debug pane. Iirc the type of enum.value contains the variant name, so at the very least you wouldnt have to track it manually