Clarify layout of tuples when last field is unsized

[Darksonn]

This is a follow-up to rust-lang/rust#137728.

Note that we only removed coercions, which is what relied on the layout matching. Tuple types with unsized last field are still legal in the language:

use core::ptr::slice_from_raw_parts;

fn main() {
    let array = [1u8; 20];

    let ptr = slice_from_raw_parts(array.as_ptr(), 20 - size_of::<i32>());
    println!("{:?}", unsafe { &*(ptr as *const (i32, [u8])) });
}

(16843009, [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1])

playground

One way to rationalize this is that it's not different from the fact that these two types might have incompatible layouts:

// A and B may have incompatible layouts

struct A(i32, [u8; 20]);
struct B(i32, [u8]);

[Darksonn]

r? @oli-obk

[rustbot]

Failed to set assignee to oli-obk: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[oli-obk]

It's only still legal because it causes regressions in dead code to remove it.

You can't construct values of such tuples soundly. There is no specified layout of such tuples, so I'd prefer not to document any layout and instead state " type that can't be instantiated, solely used for type system shenanigans"

[Darksonn]

This PR does not document any layout of such tuples. It adds a note to clarify that a certain guarantee is not made.

[oli-obk]

Yes, but it still implies these types are useful. At the start of the section it says tuples don't have a specified layout. What value does the note add?

[Darksonn]

It says that tuples have the same layout as structs, and for structs it is sometimes the case that the last field is guaranteed to be laid out at the end even if repr(rust) is used. Furthermore, it has previously been the case that tuples were always laid out in this manner (and maybe we still do so?).

You can't construct values of such tuples soundly.

I don't agree with this claim. Yes, the compiler has a certain freedom in what the precise layout is, but we say it has the repr(rust) layout, and we do in fact document certain guarantees about repr(rust). In my example, if we add an assertion that the size/alignment rustc decides to pick is compatible with the buffer, then any codepath that passes the assertion does not trigger UB.