質問の歴史:
RFC 1758 以前、Rust には FFI におけるゼロコスト newtypes のメカニズムが欠けていました。開発者は、決定的なレイアウトを強制する #[repr(C)] に依存しましたが、無駄なパディングが発生する可能性があります。また、フィールドの順序変更やニッチの悪用を許可する #[repr(Rust)] もありました。これにより、ラッパー構造体を介した型安全性の強制と、外国関数呼び出しのための ABI の安定性の保証の間に根本的なジレンマが生じました。#[repr(transparent)] はこの緊張を解決するために導入され、正確に1つの非零サイズフィールドを含む構造体が、その基になるフィールドと同一のメモリレイアウト、アライメント、およびコールコンベンションを持つことを約束しました。
問題:
#[repr(Rust)] の newtype が、原始的な内部型（例：u32 ハンドル）を期待する外国関数に参照または値として渡されると、コンパイラはラッパーのフィールドを再配置したり、ニッチ最適化を適用したりする自由があります。#[repr(Rust)] は安定性の保証を提供しないため、ラッパーは内部型とは異なるサイズやビットパターンの有効性、またはパディングを持つ可能性があります。これにより、外国の C コードが不正確なメモリを読み取り、不正なビットパターンを有効なポインタとして解釈したり、ゴミデータにアクセスしたりすることになり、未定義の動作やメモリの破損を引き起こすことになります。
解決策:
#[repr(transparent)] は、ラッパーとその単一の非零フィールドが同一のサイズ、アライメント、ABI を共有することをコンパイラに強制します。これにより、ラッパーはコンパイル時のみの抽象として機能します。コンパイラは、正確に1つのフィールドが非ゼロサイズを持つこと（追加の PhantomData や単位型フィールドを許可）を静的に検証します。これにより、ラッパーは内部型に安全に変換されたり、FFI の境界を越えて直接渡されたりできます。以下に示すように:
#[repr(transparent)] pub struct SocketFd(i32); extern "C" { fn close_socket(fd: i32); } pub fn close(sock: SocketFd) { // 安全: SocketFd は i32 と同一の ABI を持つ unsafe { close_socket(sock.0); } }
ある開発者が Rust アプリケーションを Linux カーネルの netlink ソケット API と統合し、未加工の整数ファイルディスクリプタを介して通信します。ソケット型が間違って混ざるのを防ぐために、struct NetlinkSocket(i32) を newtype として定義します。最初は #[repr(Rust)] でマークされ、外部の extern "C" コールバックに i32 へのポインタを期待して NetlinkSocket への参照を渡します。ローカル開発中は正しく機能しているように見えましたが、LTO（リンク時最適化）を利用するリリースビルドでは、コンパイラが NetlinkSocket に対して積極的なニッチ最適化を適用し、そのメモリ表現が根本的に変更されます。その後、C カーネルモジュールは破損したポインタ値を受け取り、重大なカーネルパニックを引き起こします。
3つの異なる解決策が評価されました。まず、#[repr(C)] を使用して安定した決定的なレイアウトを強制することが考慮されました。この方法はメモリ安全性を確保しましたが、有益なニッチ最適化を無効にし、パディングバイトを追加する可能性があり、構造体のサイズを不必要に膨張させ、純粋な Rust 内部使用のための API 表面を複雑にしました。
次に、毎回の FFI コールサイトで内部フィールド（socket.0）を手動で参照解除する試みがありました。このアプローチはレイアウトの仮定を避けましたが、非常にエラーが発生しやすく冗長であり、実質的に抽象の境界を壊し、生の無型整数がコードベース全体で無制限に伝播する可能性を許しました。
3つ目は、NetlinkSocket に #[repr(transparent)] を適用したことでした。この保証により、i32 と ABI の同等性が確保されつつ、Rust 内の型の区別が保持され、構造体が手動のアンラッピングや変換ロジックなしで C にシームレスに渡されることが可能になりました。
エンジニアリングチームは最終的に #[repr(transparent)] を採用し、カーネルパニックを完全に排除しつつゼロコストの抽象を維持しました。ラッパーは、Rust 内で厳格なコンパイル時の保護として機能し、C ABI と完全に互換性を持ちながら、全く目に見えないものとなりました。
なぜ #[repr(transparent)] は単一の非零フィールドをゼロサイズ型にすることを明示的に禁止し、この制限が FFI で値として渡す際の未定義動作をどのように防ぐのか？
#[repr(transparent)] は、ラッパーがその内部型と ABI が同一であることを保証します。ゼロサイズ型（ZST） はサイズがゼロでアライメントが1です。もしラッパーが専ら ZST をラップすることが許可されていた場合、結果として得られる構造体もゼロサイズとなります。しかし、C はゼロサイズ型を持たず、その呼び出し規約は通常「値渡し」セマンティクスのために少なくとも1バイトのデータを期待します。FFI で ZST を値として渡すことは未定義の動作を構成します。なぜなら C はゼロサイズの値を適切に表現したり処理したりできないからです。この制限は、ラッパーが常にその基になるフィールドと同じ非ゼロサイズおよびアライメントを維持し、C の期待に互換性のある明確に定義された ABI を保持することを保証します。
#[repr(transparent)] を列挙型に適用できますか、また、識別子の可視性を FFI 境界を越えて制御する制約は何ですか？**
はい、#[repr(transparent)] は、ちょうど1つのバリアントを含む列挙型に適用できますが、そのバリアント自体は正確に1つの非ゼロサイズフィールドを含む必要があります。また、列挙型は識別子の型を定義するために明示的なプリミティブな表現（例：#[repr(u8)]）を指定しなければなりません。ただし、#[repr(transparent)] は最終的なレイアウトが 非零フィールド と同一であることを保証します。したがって、そのような列挙型を基になるフィールド型として C に渡すことは安全ですが、C から識別子値にアクセスしたり解釈したりしようとすると未定義動作が発生します。候補者はしばしば、識別子が物理的にレイアウトから存在しないことを誤解しているか、単に隠されているかアクセス不能であると誤認しています。
#[repr(transparent)] 構造体の追加フィールドとしての PhantomData<T> の存在は、ABI に影響を与えずに変異性とドロップチェックにどのように影響しますか？**
PhantomData<T> は、#[repr(transparent)] 構造体内の二次フィールドとして明示的に許可されます。なぜなら、これはゼロサイズでアライメントが1だからです。ラッパーのサイズ、アライメント、または ABI は変わりません（#[repr(transparent)] がレイアウトに対して単一の非ゼロフィールドのみを考慮するため）、しかし、これはコンパイラに型パラメータ T との構造的関係を通知します。これは変異性に影響を与えます：例えば、Wrapper<T>(*const T, PhantomData<fn(T)>) 構造体は、PhantomData マーカーのために T に対して逆変となります。さらに、ドロップチェック（dropck）の分析を有効にし、この構造体が概念的に T 型のデータを所有する可能性があることを認識させ、不完全性を防ぎます。候補者はしばしば PhantomData がメモリレイアウトに影響を与えると誤解するか、またはジェネリック FFI ラッパーのライフタイムと所有権の不変性を維持するために重要な役割を無視します。