From 949aebb16128c4561c6025550f1ea99febb0da4f Mon Sep 17 00:00:00 2001 From: gnzlbg Date: Thu, 5 Dec 2019 20:34:57 +0100 Subject: [PATCH] Guarantee layout of homogeneous tuples Closes #36 . --- reference/src/layout/packed-simd-vectors.md | 30 ++------------------- reference/src/layout/structs-and-tuples.md | 11 +++----- 2 files changed, 6 insertions(+), 35 deletions(-) diff --git a/reference/src/layout/packed-simd-vectors.md b/reference/src/layout/packed-simd-vectors.md index ed7b871b..890a5d7b 100644 --- a/reference/src/layout/packed-simd-vectors.md +++ b/reference/src/layout/packed-simd-vectors.md @@ -45,12 +45,12 @@ That is, two distinct `repr(simd)` vector types that have the same `T` and the same `N` have the same size and alignment. Vector elements are laid out in source field order, enabling random access to -vector elements by reinterpreting the vector as an array: +vector elements by reinterpreting the vector as an array or as an homogeneous tuple: ```rust,ignore union U { vec: Vector, - arr: [T; N] + arr: [T; N], } assert_eq!(size_of::>(), size_of::<[T; N]>()); @@ -66,32 +66,6 @@ unsafe { ``` ### Unresolved questions - -* **Blocked**: Should the layout of packed SIMD vectors be the same as that of - homogeneous tuples ? Such that: - - ```rust,ignore - union U { - vec: Vector, - tup: (T_0, ..., T_(N-1)), - } - - assert_eq!(size_of::>(), size_of::<(T_0, ..., T_(N-1))>()); - assert!(align_of::>() >= align_of::<(T_0, ..., T_(N-1))>()); - - unsafe { - let u = U { vec: Vector(t_0, ..., t_(N - 1)) }; - - assert_eq!(u.vec.0, u.tup.0); - // ... - assert_eq!(u.vec.(N - 1), u.tup.(N - 1)); - } - ``` - - This is blocked on the resolution of issue [#36] about the layout of - homogeneous structs and tuples. - - [#36]: https://github.com/rust-rfcs/unsafe-code-guidelines/issues/36 * `MaybeUninit` does not have the same `repr` as `T`, so `MaybeUninit>` are not `repr(simd)`, which has performance diff --git a/reference/src/layout/structs-and-tuples.md b/reference/src/layout/structs-and-tuples.md index 53bcee3d..794272a4 100644 --- a/reference/src/layout/structs-and-tuples.md +++ b/reference/src/layout/structs-and-tuples.md @@ -24,6 +24,10 @@ guaranteed layout from a tuple, you are generally advised to create a named struct with a `#[repr(C)]` annotation (see [the section on structs for more details](#structs)). +Homogeneous tuples have the same layout as an array `[T; N]` where `N` is the +number of fields in the tuple and the tuple field `i` is located at the same +offset as the `i`-th array element. + Note that the final element of a tuple (`Pn`) is marked as `?Sized` to permit unsized tuple coercion -- this is implemented on nightly but is currently unstable ([tracking issue][#42877]). In the future, we may @@ -207,13 +211,6 @@ issue has been opened for further discussion on the repository. This section documents the questions and gives a few light details, but the reader is referred to the issues for further discussion. -**Homogeneous structs ([#36]).** If you have homogeneous structs, where all -the `N` fields are of a single type `T`, can we guarantee a mapping to -the memory layout of `[T; N]`? How do we map between the field names -and the indices? What about zero-sized types? - -[#36]: https://github.com/rust-rfcs/unsafe-code-guidelines/issues/36 - **Deterministic layout ([#35]).** Can we say that layout is some deterministic function of a certain, fixed set of inputs? This would allow you to be sure that if you do not alter those inputs, your struct layout would