google / google/zerocopy

Support container transmutation via macro

Open
#1,735 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
Rust
Stars
2.6k
Forks
179
Avg merge
1d 19h
Merged PRs (30d)
29

Description

*This is one possible avenue for supporting #114.*

*A draft implementation is in #1736.*

Most container transmutations require three components:
1. `Src: FromBytes + IntoBytes + Immutable` and `Dst: FromBytes + IntoBytes + Immutable`
2. `size_of::() == size_of::()` and `align_of::() == align_of::()`
3. Some way of invoking the right `into_raw` and `from_raw` associated functions on the container type

Currently, macros like `transmute_ref!` have the ability to enforce conditions (1) and (2). It should be possible in principle to support condition (3) using a trait:

```rust
#[doc(hidden)]
pub unsafe trait Container {
type Element;
type Raw;

fn into_raw(self) -> Self::Raw;
unsafe fn from_raw(Self::Raw) -> Self;
}
```

The associated `Raw` type is needed because not all containers use the same raw representations. For example, [`Arc` uses `*const T`](https://doc.rust-lang.org/std/sync/struct.Arc.html#method.into_raw) while [`Vec` uses `(*mut T, usize, usize)`](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.into_raw_parts).

A few open questions:
- In order to perform the size and alignment checks, we need Rust to be able to infer the types of certain variables. This is easy with `transmute_ref!`, but how would we do it when those types are inside containers? Off the top of my head, I *think* it should be possible via a function like `fn unwrap(c: C) -> C::Element`.
- Can we relax the trait bounds only in certain cases? E.g., `Arc` only requires `Src: IntoBytes + Immutable` and `Dst: FromBytes + Immutable`, but does not require `Src: FromBytes` or `Dst: IntoBytes`

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.