The important change here appears to be that the internal representation of a vtable is now guaranteed to have its supertraits laid out in some predictable prefix form to its own methods.
EDIT: or if this is not possible, a pointer to the appropriate vtable is included. I assume this must be for diamond trait inheritance.
> the internal representation of a vtable is now guaranteed to have its supertraits laid out in some predictable prefix form to its own methods.
Importantly, note that the specifics of the vtable layout are not guaranteed, only the general property that the layout must be amenable to supporting this.
IIRC vtable happens to already be laid out the required way (barring some corner cases maybe, correct me if I am wrong), this RFC just made that official.
And for diamond patterns vtable entries are duplicated.
Comments
The important change here appears to be that the internal representation of a vtable is now guaranteed to have its supertraits laid out in some predictable prefix form to its own methods.
EDIT: or if this is not possible, a pointer to the appropriate vtable is included. I assume this must be for diamond trait inheritance.
> the internal representation of a vtable is now guaranteed to have its supertraits laid out in some predictable prefix form to its own methods.
Importantly, note that the specifics of the vtable layout are not guaranteed, only the general property that the layout must be amenable to supporting this.
And for extra context the RFC lays out the current design and future options: https://github.com/rust-lang/rfcs/blob/master/text/3324-dyn-...
IIRC vtable happens to already be laid out the required way (barring some corner cases maybe, correct me if I am wrong), this RFC just made that official.
And for diamond patterns vtable entries are duplicated.