Do not consider uninhabited 1-ZST "trivial" for the purpose of repr(transparent)?

[RalfJung]

Currently, repr(transparent) ignores all 1-ZST, including uninhabited types. Together with the ABI promise we are making for repr(transparent), that means we cannot in any way exploit the uninhabitedness of a type for the purpose of the function call ABI -- which has led to #135802; we had to actually pessimize the ABI for functions returning things like (i32, !) to account for this. (Cc @zachs18)

@rust-lang/lang is that a deliberate feature of repr(transparent)? It seems more like an accident to me.

However, it is an accident that is non-trivial to fix, since it turns out hyper contains a type like this:

#[repr(transparent)]
struct Neutered<B> {
    _inner: B,
    impossible: Impossible,
}

enum Impossible {}

Under a more reasonable set of rules for repr(transparent) that does not just ignore uninhabited 1-ZST, this type would be rejected. @seanmonstar @nox is there any particular reason why this type is repr(transparent)? It is still uninhabited, making it insta-UB to create an element, even by transmutation from B.

A crater run has been queued in #147589.

[RalfJung]

@traviscross in terms of scheduling, if you anyway have a backlog to deal with it could make sense to wait until the crater results are in before discussing this issue.

[seanmonstar]

I'm hazy, trying to page that in from a while ago (and I didn't write it), so my understanding could be wrong, but here's what I gleaned right now:

The type is meant to signal internally that certain variants of an enum are impossible to product while that type is used. We have (paraphrased):

enum SendBuf<B> {
    User(B),
    Cursor(Box<[u8]>),
}

So by having a Sender<SendBuf<Neutered<B>>, we've promised at that point that a SendBuf::User(Neutered {}) can never be sent.

And it looks like the repr(transparent) is used so that we can transmute the whole handle, and just have some code paths that use the neutered type.

It's possible @nox could correct my understanding.

---

Is the way we've used it a significant problem? I could spend some time to refactor if it's important.

[RalfJung]

So the idea is that you want to transmute between SendBuf<B> and SendBuf<Neutered<B>>? I don't think that's guaranteed to work -- just because A and B have the same layout, doesn't imply that that's also the case for Enum<A> and Enum<B>. This is already the case for e.g. A = *mut T and B = NonNull<T>, and proposals like rust-lang/compiler-team#922 would seem to me like they'd in fact break the exact transmute you are describing here: SendBuf<Neutered<B>> would not even get a tag since there's only one inhabited variant so no runtime information is needed to encode the active variant.

(I'm assuming there's no repr attribute on SendBuf. If that type is repr(C), that would change things.)

Is the way we've used it a significant problem? I could spend some time to refactor if it's important.

Currently we're in the information gathering phase of this issue. I'm trying to figure out if there's some use-case we're breaking by considering inhabitedness for repr(transparent). Right now it seems to me like this particular usecase is already working only by accident and is at risk of being broken by other changes, too. Would be good to figure out a way to put this on solid footing without relying on unstable aspects of enum layout. If you have ideas for how to do that, that'd be helpful. :)

[programmerjake]

seems like we'd want to somehow support uninhabited repr(transparent) types for FFI, e.g. you can write the following in C:

[[noreturn]] int foo(int a);
struct Big {
    char v[1024];
};
[[noreturn]] struct Big bar(int a);

here foo and bar have a different ABI, bar presumably has to pass in a pointer for returning Big so would use a different register for a than foo would.

imo the rust equivalent would be:

#[repr(transparent)]
pub struct NoReturn<T>(pub T, !);

#[repr(C)]
pub struct Big {
    pub v: [c_char; 1024],
}

unsafe extern "C" {
    fn foo(a: c_int) -> NoReturn<c_int>;
    fn bar(a: c_int) -> NoReturn<Big>;
}