LLDB doesn't yet have a TypeSystemRust implemented however it is used to debug Rust applications. Most of the types map well enough to Clang types and there are python formatters implemented to display those types reasonably well in a debugger. We discussed this with Greg Clayton internally and this approach looks like a reasonable thing to implement and fix one of the major pain points when debugging Rust with LLDB.
However, Rust enums are completely ignored by LLDB as Clang never emits DW_TAG_variant_part inside DW_TAG_structure_type
This diff adds a parser for DW_TAG_variant_part (Rust-only) that creates a matching valid Clang declaration that represents a Rust enum. As long as there is enough information and all fields have correct offsets synthetic/summary providers can be implemented to display it correctly when debugging Rust code
For example given a Rust enum:
enum EnumOpt2 {
A(u8),
B(bool),
}The following is a matching Clang declaration:
struct EnumOpt2 {
union debugger_test::EnumOpt2$Inner {
struct A$Variant {
unsigned char $discr$;
debugger_test::EnumOpt2::A value : 8;
};
debugger_test::EnumOpt2::debugger_test::EnumOpt2$Inner::A$Variant $variant$0;
struct B$Variant {
unsigned char $discr$;
debugger_test::EnumOpt2::B value : 8;
};
debugger_test::EnumOpt2::debugger_test::EnumOpt2$Inner::B$Variant $variant$1;
};
struct A {
unsigned char __0;
};
struct B {
bool __0;
};
debugger_test::EnumOpt2::debugger_test::EnumOpt2$Inner inner;
}Now this declaration contains all the necessary information to interpret the original Rust enum in a Python synthetic formatter and display back on UI as Rust enum.
Store variant_name as a ConstString instead of creating one each time. Creating a ConstString (even if the string is in the StringPool) has a non-trivial creation cost.