thin_trait_object
One pointer wide trait objects which are also FFI safe, allowing traits to be passed to/from and implemented by C ABI code.
Trait objects in Rust suffer from several fundamental limitations:
- Pointers have twice the size because trait objects are constructed with a pointer coercion rather than a value transformation — this means that the [virtual dispatch table] or a pointer to one cannot be stored inside the object and has to accompany pointers to that object, increasing size overhead for the pointers, especially for collections like Vec<Box<dyn ...>>;
- Passing trait objects over an FFI boundary is impossible because they do not have a defined memory layout and implementation;
- No way to manually construct a trait object given only a dispatch table and a value, i.e. to create a custom implementation which does not correspond to any type's implementation of the trait.
For most purposes, those limitations are relatively easy to work around or are not applicable at all. However, in several scenarios, there is no possible solution and that is inherent to the nature of how trait objects work in Rust. Examples include:
- Implementing a plugin system where plugins residing inside dynamically loaded libraries (.dll/.so/.dylib) can be loaded by Rust code and then be used to extend the functionality of the base program using a defined interface;
- Decreasing storage overhead for references/boxes/pointers to trait objects, as in the Vec<Box<dyn ...>> example;
- Implementing traits via JIT compilation of a different language, though this is a very niche scenario.
All those workloads fit the pattern of trait objects but don't fit the implementation. This crate serves as an alternate implementation of trait objects which serves the pattern while overcoming limitations of the compiler's built-in implementation. The functionality is provided in the form of an easy-to-use atttribute macro.
The macro was heavily inspired by the design and implementation of an FFI-safe trait object described in the [FFI-Safe Polymorphism: Thin Trait Objects] article by Michael-F-Bryan. The article is a walkthrough for writing such a trait object manually, and this crate serves as the macro to perform the same task in an automated fashion.
The most basic use case: ```rust use thintraitobject::*;
trait Foo {
fn fooify(&self);
}
impl Foo for String {
fn fooify(&self) {
println!("Fooified a string: {}", self);
}
}
BoxedFoo::new("Hello World!".to_string()).fooify();
``
The macro will generate two structures (there's a third one but that's an implementation detail):
- **FooVtable**, the dispatch table (vtable) — a#[repr(C)]structure containing type-erased function pointer equivalents to all methods in the trait, as well as an additionaldropfunction pointer called byBoxedFoowhen it gets dropped (another attribute,#[derive(Copy, Clone, Debug, Hash)], is added by default);
- **BoxedFoo**, analogous toBoxin that it acts as a valid implementation of theFootrait and has exclusive ownership of the contained value, which has the same memory layout as a [core::ptr::NonNull] to a type which implementsSized`.
Both of those will have the same visibility modifier as the trait on which the #[thin_trait_object] attribute is placed, unless you override it — the section up ahead is there to explain how.
The basic invocation form, #[thin_trait_object], will use the reasonable defaults for all possible configuration values. To override those configuration parameters, the following syntax is used:
```rust
parameter1(value_for_the_parameter),
parameter2(another_value),
// Certain parameters require a slightly different syntax, like this:
parameter3 = value,
)]
trait Foo {
...
}
``
The following options are supported:
-vtable(
By default, #[repr(C)] and #[derive(Copy, Clone, Debug, Hash)] are attached, the visibility is taken from the trait definition, and the name is of form <trait_name>Vtable, as in MyTraitVtable.
#[repr(C)] will be overriden, while the #[derive(...)] will not be, meaning that specifying #[derive(PartialEq)], for example, will add PartialEq to the list of traits being derived without overriding it.
Example:
rust
#[thin_trait_object(
vtable(
/// Documentation for my generated vtable.
#[repr(custom_repr)] // Will override the default #[repr(C)]
#[another_fancy_attribute]
pub MyVtableName // No semicolon allowed!
)
)]
trait_object(<attributes> <visibility> <name>) — same as vtable(...), but applies its effects to the generated boxed trait object structure.
Cannot attach a #[derive(...)] attribute for soundness reasons (so that a #[derive(Copy)] wouldn't lead to undefined behavior without any usage of the unsafe keyword on the macro usage site.)
By default, #[repr(transparent)] is attached (cannot be overriden), the visibility is taken from the trait definition, and the name is of form Boxed<trait_name>, as in BoxedMyTrait.
inline_vtable = <true/false> — specifies whether the vtable should be stored directly in the trait object (true) or be stored as a &'static reference to the vtable. Set to false by default, and overriding this is not recommended unless the trait has very few (one or two) methods, or it is absolutely necessary to override this in order to be compatible with certain third-party code.
Example: ```rust
inline_vtable = true )] ```
drop_abi = "..." — specifies the ABI (the "C" in extern "C") for the drop function pointer in the vtable. The ABI for all other methods in the vtable can be specified in the trait definition directly.
Example: ```rust
drop_abi = "C" // Equivalent to extern "C" on a function/method )] ```
marker_traits(...) — specifies a comma-separated list of traits which are to be considered marker traits, i.e. be implemented via an empty impl block on the generated thin trait object structure if the trait definition lists them as supertraits. Unsafe traits in the list need to be prefixed with the unsafe keyword.
By default, the list is marker_traits(unsafe Send, unsafe Sync, UnwindSafe, RefUnwindSafe).
See the Supertraits section for more on how the macro interacts with supertraits.
Example: ```rust trait SafeTrait {} unsafe trait UnsafeTrait {}
marker_traits(
SafeTrait,
// unsafe keyword here ensures that "unsafe code" is required
// to produce UB by implementing the trait
unsafe UnsafeTrait,
)
)]
trait MyTrait: SafeTrait + UnsafeTrait {}
```
store_layout = <true/false> — specifies whether the generated vtable should also contain the size and align fields, storing the size of the stored type and its preferred alignment respectively. Set to false by default for compatibility.
Example: ```rust
store_layout = true )] ```
One of the main focuses of the macro is FFI, which is why usage of the macro with FFI is simple and natural: ```rust use thintraitobject::*; use std::ffi::c_void;
trait Foo { extern "C" fn say_hello(&self); }
impl Foo for String { extern "C" fn say_hello(&self) { println!("Hello from \"{}\"", self); } }
extern "C" { fn eateroffoo(foo: *mut cvoid); fn creatoroffoo() -> *mut cvoid; }
let foo = BoxedFoo::new("Hello World!".to_string());
unsafe {
// Will transfer ownership to the C side.
eateroffoo(foo.intoraw() as *mut cvoid);
}
// Acquire ownership of a different implementation from the C side.
let foo = unsafe { BoxedFoo::fromraw(creatoroffoo() as *mut ()) };
foo.sayhello();
The C side would do:
c
typedef void (vtable_say_hello)(void); typedef void (vtable_drop)(void); typedef struct foovtable { vtablesayhello sayhello; vtabledrop drop; } foovtable;
void eateroffoo(void* foo) { // The first field is a pointer to the vtable, so we have to first // extract that pointer and then dereference the function pointers. foovtable* vtable = *((foovtable**)foo);
// Have to provide the pointer twice, firstly for
// lookup and then to provide the &self reference.
vtable.say_hello(foo);
// Don't forget about manual memory management — the C side owns the trait object now.
vtable.drop(foo);
} void* creatoroffoo(void) { // Allocate space for one pointer, the pointer to the vtable. void* allocation = malloc(sizeof(foovtable*)); void* vtablepointer = &customvtable; // Put the pointer into the allocation. memcpy(allocation, &vtablepointer, sizeof(foo_vtable*)); return allocation; }
static foovtable customvtable { // Using C11 designated initializers, consult your local C expert for // ways to do this on an old compiler. .sayhello = &implsayhello, .drop = &impldrop }; void implsayhello(void* self) { puts("Hello from C!"); } void impl_drop(void* self) { free(self); } ```
Consider this situation: ```rust use thintraitobject::*;
trait A { fn a(&self); }
trait B: A {
fn b(&self);
}
This will fail to compile because the macro will try to implement `B` for `BoxedB`, the generated thin trait object structure, which will fail because `BoxedB` doesn't implement `A`. To fix this, that must be done manually:
rust
trait B: A {
fn b(&self);
#[doc(hidden)]
fn thunka(&self) {
self.a(); // Redirect to the method from the A trait implementation
}
}
impl A for BoxedB<'> {
fn a(&self) {
// Redirect to the hidden thunk, which will use the actual implementation of the method
self.thunk_a();
}
}
``
This is necessary because the macro has no access toA` and thus doesn't know that it needs to add its methods to the vtable.
A little hacky, but there is no cleaner way of doing this using only procedural macros. If you have any suggestions for improving this pattern, raise an issue explaining your proposed solution or create a PR.
The following is a comprehensive list of everything the macro emits: - The trait itself, with all other attributes. - A virtual dispatch table struct definition.
The name can be customized via the vtable(...) configuration option (see the Configuring the macro section); the default name is {trait name}Vtable, as in, FooVtable for a trait named Foo.
The virtual dispatch table is defined as follows:
rust
#[repr(C)] // Can be customized via configuration options
#[derive(Copy, Clone, Debug, Hash)]
struct FooVtable {
// One field for every method in the trait
drop: unsafe fn(::core::ffi::c_void), // ABI can be customized via configuration options
}
The other fields, ones besides drop, each have the same name as their corresponding trait method. The signatures are nearly identical, with two differences:
- &self or &mut self, if present, are replaced with [*mut ::core::ffi::c_void][core::ffi::c_void];
- If there was no unsafe on the trait method, it is added automatically, since the pointer passed as the first argument is never validated.
- A thin trait object struct definition.
The name can be customized via the trait_object(...) configuration option (see the Configuring the macro section); the default name is Boxed{trait name}, as in, BoxedFoo for a trait named Foo.
The virtual dispatch table is defined as follows:
rust
#[repr(transparent)]
struct BoxedFoo<'inner>(
::core::ptr::NonNull<{vtable name}>,
::core::marker::PhantomData<&'inner ()>,
);
If the trait has a 'static lifetime bound, the 'inner lifetime parameter is not emitted, since all possible contained implementations are restricted to be 'static.
The following methods and associated functions are present on the boxed thin trait object structure:
- rust
fn new<T: {trait name} + Sized + 'inner>(val: T) -> Self
Constructs a boxed thin trait object from a type implementing the trait. The 'inner bound is replaced with 'static if the 'static lifetime is one of the supertraits on the base trait.
- rust
const unsafe fn from_raw(ptr: *mut ()) -> Self
Creates a thin trait object directly from a raw pointer to its vtable.
### Safety
This constructor, by its nature, is hugely unsafe and should be avoided when possible. The following invariants must be upheld:
- The pointer must not be null and must point to a valid thin trait object as expected by its vtable which is not uninitialized;
- The function pointers in the vtable must not be null and must point to valid functions with correct ABI and signature;
- The function pointers must have the same safety contract as implied and not a stronger one: only cause UB if the vtable pointer passed to them is invalid or, if those are unsafe in the trait itself, cause UB if the safety contract in their declarations is violated;
- If the trait is unsafe, the function pointers must follow the trait's contract for valid implementations;
- The pointer was not returned by `as_raw` which was called on an object which was not put into [`ManuallyDrop`] or consumed by [`mem::forget`], otherwise undefined behavior will be invoked when both are dropped.
- rust
const fn as_raw(&self) -> *mut ()
Extracts the contained pointer to the trait object.
Unlike `into_raw`, ownership of the pointer is not released, and as such will be dropped normally. Unless the original copy is removed via [`mem::forget`] or [`ManuallyDrop`], calling `from_raw` and then dropping will cause undefined behavior.
- rust
fn into_raw(self) -> *mut ()
Releases ownership of the trait object, returning the contained pointer. It is the caller's responsibility to drop the trait object at a later time using from_raw.
For a version which does not release ownership, see `as_raw`.
- rust
fn vtable(&self) -> &{vtable name}
Retrieves the raw vtable of the contained trait object.