Regression in lint for non-exhaustive ZST in repr(Transparent)

[compiler-errors]

Lifted from #78586

---

I believe this future compatibility warning was badly affected by #115334. Minimal repro:

// src/lib.rs

#[non_exhaustive]
pub struct ZeroSizedNonExhaustive {}

// src/main.rs

#![deny(warnings)]

#[repr(transparent)]
pub struct Transparent(repro::ZeroSizedNonExhaustive);

fn main() {}

As far as I understand what this issue is about, this code should be 100% fine. This issue is about preventing a previously-accepted repr(transparent) struct from ending up with contents which a transparent struct is not allowed to have, after a permissible size increase of a non-exhaustive formerly-ZST from a different crate.

That's not possible in the code above. Transparent continues to be a valid repr(transparent) struct if ZeroSizedNonExhaustive increases in size.

Regression in nightly-2023-09-18:

error: zero-sized fields in `repr(transparent)` cannot contain external non-exhaustive types
 --> src/main.rs:6:24
  |
6 | pub struct Transparent(repro::ZeroSizedNonExhaustive);
  |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #78586 <https://github.com/rust-lang/rust/issues/78586>
  = note: this struct contains `ZeroSizedNonExhaustive`, which is marked with `#[non_exhaustive]`, and makes it not a breaking change to become non-zero-sized in the future.

@RalfJung @compiler-errors

Originally posted by @dtolnay in #78586 (comment)

[RalfJung]

Ah... good catch. When a type is not "stably 1-ZST" we should just consider it the one non-1-ZST field. Though given that this is a lint right now the logic is a bit trickier... we need to remember if there was a non-1-ZST field, and then

• if there was, all 1-ZST fields need to be stably 1-ZST
• if there wasn't, all but one 1-ZST field need to be stably 1-ZST. Having a nice diagnostic for this could be tricky because ideally we'd point it at two 1-ZST fields that are not stable, and explain "both of these might become non-1-ZST in the future and then this wouldn't build any more".

Sadly I won't have the time to work on fixing this quickly. Let me know if you want me to revert the PR.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high