Add debug representation of trait objects

[jdm]

Updated descrption

Trait objects (~T and @T where T is a trait) are objects that hide their implementation and carry a virtual method dispatch table (i.e. vtable).

So, two things:

1. Debuggers will want to be able to bypass the abstraction barrier and see the hidden implementation.
2. They are also likely to want to be able to see the vtable.
   • I am not sure how flexible the debug format is for gdb, but newer versions of gdb do support printing the vtable for C++ objects (via info vtbl or perhaps info vtable). It would be cool if we could massage our debug info so that gdb can just print out our vtables too, the same way.

Original description

There is none.

[pnkfelix]

What would a debug representation of a Trait be? I think of a Trait as a purely compile-time entity that is erased by the time you get to runtime.

@jdm Is this specifically for @trait objects (in which case, yes, I agree we would want to expose the vtable to the debugger?) If so, then I'll clear up the bug title and description.

[jdm]

Yes, I think scoping this to cover trait objects (of the ~ and @ variety) would be fine.

[graydon]

According to middle/trans/debuginfo.rs: cx.sess.span_note(span, "debuginfo for trait NYI");

i.e. this is still valid, properly tagged and milestoned, 2013-06-19.

[huonw]

Triage visit; deferring to @michaelwoerister.

[michaelwoerister]

Triage visit; deferring to @michaelwoerister.

It is still NYI but should be tackled some time this month.

[michaelwoerister]

Update:

As of PR #9168 there is some basic support for trait objects. A trait object pointer is described as a struct with the correct size (two pointers) and the correct name ({sigil}{mutability}{trait name}) and is placed in the correct namespace. The interior of this "fat pointer" is not described any further yet. What is missing is the description of the trait's methods. I don't know enough about how they are actually implemented to say much about that.

[catamorphism]

Not 1.0, but high

[thestinger]

@michaelwoerister: By the way, the new vtable layout is [drop_glue, method, method2, method3, ...]. I'm sure this will change in the future somehow when supertrait methods become callable on trait objects.

[nrc]

This has got more complicated with DST since you can have objects like Fat<Trait> where Fat is a DST struct. The stub code for trait objects has got a little bit more broken, but I don't want to fix it since it is just a stub. I left a FIXME there.

[steveklabnik]

Triage bump: unsure what the status is of this today.

[nrc]

still needs doing

[michaelwoerister]

We could do the following:
(1) Create a type descriptions for each trait that contains the methods it defines. Since there are no traits in the DWARF standard yet, using DW_AT_interface would make the most sense. But maybe using DW_AT_struct is more compatible with our C-oriented debuggers.

(2) Describe trait pointers (&Trait et al) as tuples of type (*(), *OpaqueVTable<Trait>).

(3) Implement custom GDB/LLDB commands in Python that, given a fat pointer, use the pointer value and type information to print the vtable.

That's not perfect but could be done with the current means available. The symbol names of the functions pointed to by the vtable should also indicate the actual runtime type of the trait object.

[nrc]

Only in builds with debug info (i.e., not release builds) and only by a pretty tiny amount