mirror of
https://github.com/rust-lang/rust
synced 2024-11-05 20:45:15 +00:00
fb2d9cdfc5
Summary: I landed a fix last year to enable `DW_TAG_variant_part` encoding in LLDBs (https://reviews.llvm.org/D149213). This PR is a corresponding fix in synthetic formatters to decode that information. This is in no way perfect implementation but at least it improves the status quo. But most types of enums will be visible and debuggable in some way. I've also updated most of the existing tests that touch enums and re-enabled test cases based on LLDB for enums. Test Plan: ran tests `./x test tests/debuginfo/`. Also tested manually in LLDB CLI and LLDB VSCode Other Thoughs A better approach would probably be adopting [formatters from codelldb](https://github.com/vadimcn/codelldb/blob/master/formatters/rust.py). There is some neat hack that hooks up summary provider via synthetic provider which can ultimately fix more display issues for Rust types and enums too. But getting it to work well might take more time that I have right now.
77 lines
2.7 KiB
Rust
77 lines
2.7 KiB
Rust
// Require a gdb or lldb that can read DW_TAG_variant_part.
|
|
//@ min-gdb-version: 8.2
|
|
//@ min-lldb-version: 1800
|
|
|
|
//@ compile-flags:-g
|
|
|
|
// === GDB TESTS ===================================================================================
|
|
|
|
// gdb-command:run
|
|
|
|
// gdb-command:print *the_a
|
|
// gdbr-check:$1 = unique_enum::ABC::TheA{x: 0, y: 8970181431921507452}
|
|
|
|
// gdb-command:print *the_b
|
|
// gdbr-check:$2 = unique_enum::ABC::TheB(0, 286331153, 286331153)
|
|
|
|
// gdb-command:print *univariant
|
|
// gdbr-check:$3 = unique_enum::Univariant::TheOnlyCase(123234)
|
|
|
|
|
|
// === LLDB TESTS ==================================================================================
|
|
|
|
// lldb-command:run
|
|
|
|
// lldb-command:v *the_a
|
|
// lldbg-check:(unique_enum::ABC) *the_a = { value = { x = 0 y = 8970181431921507452 } $discr$ = 0 }
|
|
// lldbr-check:(unique_enum::ABC::TheA) *the_a = TheA { TheA: 0, TheB: 8970181431921507452 }
|
|
|
|
// lldb-command:v *the_b
|
|
// lldbg-check:(unique_enum::ABC) *the_b = { value = { 0 = 0 1 = 286331153 2 = 286331153 } $discr$ = 1 }
|
|
// lldbr-check:(unique_enum::ABC::TheB) *the_b = { = 0 = 286331153 = 286331153 }
|
|
|
|
// lldb-command:v *univariant
|
|
// lldbg-check:(unique_enum::Univariant) *univariant = { value = { 0 = 123234 } }
|
|
// lldbr-check:(unique_enum::Univariant) *univariant = { TheOnlyCase = { = 123234 } }
|
|
|
|
#![allow(unused_variables)]
|
|
#![feature(omit_gdb_pretty_printer_section)]
|
|
#![omit_gdb_pretty_printer_section]
|
|
|
|
// The first element is to ensure proper alignment, irrespective of the machines word size. Since
|
|
// the size of the discriminant value is machine dependent, this has be taken into account when
|
|
// datatype layout should be predictable as in this case.
|
|
enum ABC {
|
|
TheA { x: i64, y: i64 },
|
|
TheB (i64, i32, i32),
|
|
}
|
|
|
|
// This is a special case since it does not have the implicit discriminant field.
|
|
enum Univariant {
|
|
TheOnlyCase(i64)
|
|
}
|
|
|
|
fn main() {
|
|
|
|
// In order to avoid endianness trouble all of the following test values consist of a single
|
|
// repeated byte. This way each interpretation of the union should look the same, no matter if
|
|
// this is a big or little endian machine.
|
|
|
|
// 0b0111110001111100011111000111110001111100011111000111110001111100 = 8970181431921507452
|
|
// 0b01111100011111000111110001111100 = 2088533116
|
|
// 0b0111110001111100 = 31868
|
|
// 0b01111100 = 124
|
|
let the_a: Box<_> = Box::new(ABC::TheA { x: 0, y: 8970181431921507452 });
|
|
|
|
// 0b0001000100010001000100010001000100010001000100010001000100010001 = 1229782938247303441
|
|
// 0b00010001000100010001000100010001 = 286331153
|
|
// 0b0001000100010001 = 4369
|
|
// 0b00010001 = 17
|
|
let the_b: Box<_> = Box::new(ABC::TheB (0, 286331153, 286331153));
|
|
|
|
let univariant: Box<_> = Box::new(Univariant::TheOnlyCase(123234));
|
|
|
|
zzz(); // #break
|
|
}
|
|
|
|
fn zzz() {()}
|