repr(transparent) accepts too many types as ZST (`repr_transparent_non_zst_fields`, formerly `repr_transparent_external_private_fields`)

[scottmcm]

This tracks eventually removing support for repr(transparent) types ignoring ZST that might not actually remain ZST in the future or on other targets.

Types that can gain more fields

In crate A:

#[non_exhaustive]
pub struct UnitType {}

In crate B:

#[repr(transparent)]
pub struct TransparentThing(i32, UnitType);

I expected that to fail in crate B, because the reason crate A put #[non_exhaustive] on the type was to allow it to get additional fields in the future, which would no longer allow it to work in repr(transparent).

But this actually compiles today, creating what I would consider an accidental semver hazard.

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Stability.20of.201-ZSTness/near/215120408

---

repr(C) types

#[repr(C)]
struct CZst([u8; 0]);

#[repr(transparent)]
pub struct TransparentThing(i32, CZst);

This should fail since CZst actually is not a ZST for all C compilers, and since the type can be relevant for the ABI.

[Mark-Simulacrum]

I'm going to nominate for lang, because I think (perhaps with a future compat lint) we should not look at foreign types' size unless that type is repr(transparent) for the purposes of checking here.

[scottmcm]

Note that this also applies to the way this was done before non_exhaustive:

pub struct UnitType(());

As that private field also keeps others from constructing or exhaustively matching it, but it would still be accepted as 1-ZST by repr(transparent).

We discussed this in the lang team meeting today. The consensus was that this is an accidental semver hazard that we'd like to do something about.

@rustbot modify labels: +E-help-wanted +E-medium

It'd be great to get a PR we could use to determine the impact of this. Ideally this isn't happening in the wild and can just be an error (maybe for one case or the other, if one is common and the other isn't) but it'll probably need at least a future imcompatibility lint.

[jsomedon]

Hello folks, can I take this issue? I am kinda new to the community but I want to start contributing. :-)

[scottmcm]

@jsomedon Absolutely! Unfortunately I don't really know the code here, so don't have suggestions for where to start, but you could always try tracing through the code around non_exhaustive and dropping by zulip if you run into any trouble.

[jsomedon]

Should a non-exhaustive struct be fine to stay in repr(transparent) in its own crate? (My understanding is that it's okay? As you can do whatever u want with the non-exhaustive in its own defining crate?)

[scottmcm]

@jsomedon Yes, I think that's ok, like how one can exhaustively match it inside its own defining crate.

[basil-cow]

@jsomedon do you plan to continue working on this?