DWARF omits typedef

[tromey]

I'm using rustc from the Fedora COPR:

bapiya. rustc --version
rustc 1.7.0 (a5d1e7a59 2016-02-29)

Consider this program:

pub type Xty = fn() -> u32;

fn x() -> u32 {
    return 57u32;
}

pub static AA: Xty = x;

fn main() {
    println!("{}", AA());
}

I compile this with -g and then look for the type Xty in the DWARF using readelf. It isn't there:

bapiya. readelf -wi B1 | grep Xty
bapiya. 

If I examine the type of AA, it ends up here:

 <1><14b>: Abbrev Number: 11 (DW_TAG_pointer_type)
    <14c>   DW_AT_type        : <0x154>
    <150>   DW_AT_name        : (indirect string, offset: 0x4b): fn() -> u32
 <1><154>: Abbrev Number: 12 (DW_TAG_subroutine_type)
    <155>   DW_AT_type        : <0x159>
[...]

That is, the typedef has been dropped.

[rphmeier]

As far as I understand, typedefs are not distinct from their definitions, so this is not strictly incorrect.

[tromey]

It's a QoI issue, in that a user can see things named in the source and then not be able to examine them in the debugger. In this case I was hoping for ptype Xty to work, or for whatis AA to print Xty.

One way this can affect real users is that it breaks the "cut and paste" principle -- that, ideally, one should be able to cut an expression from a program and paste it into the debugger and get the correct evaluation. Here this would fail with a cast expression because the type name is not available.

[sanxiyn]

At the moment, rustc throws away typedef information long before debug info is generated. It actually happens before type checking, resulting in type error message QoI issue like #25694. So this is quite nontrivial to fix.

[wesleywiser]

Visited during wg-debugging triage. This still repros in 2022 and while we should try to improve this eventually to help us reach the ideal future of "debugging is delightful", this doesn't prevent users from debugging their code today. Therefore, triaging as P-low.