repr(transparent): it's fine if the one non-1-ZST field is a ZST

[RalfJung]

This code currently gets rejected:

#[repr(transparent)]
struct MyType([u16; 0])

That clearly seems like a bug to me: repr(transparent) got defined as having any number of 1-ZST fields plus optionally one more field; MyType clearly satisfies that definition.

This PR changes the repr(transparent) logic to actually match that definition.

[rustbot]

r? @TaKO8Ki

(rustbot has picked a reviewer for you, use r? to override)

[RalfJung]

Nominating for T-lang since this is a change in public behavior on stable -- but we already had an FCP blessing this so I don't think we need a full FCP again.

[fmease]

That's great, when working on a fix for #90435 (which is now sadly blocked on #114952 I guess), I've noticed that

#[repr(transparent)] struct S(_1Zst, Zst);
struct _1Zst;
#[repr(align(2))] struct Zst;

currently doesn't compile. This should be fixed by this PR, right?

[RalfJung]

Yes that should be fixed by this PR.

[scottmcm]

I agree that this doesn't need another lang sign-off since it's what was explicitly FCP'd before. (Sadly we didn't get to it in the meeting today, so I'm only speaking for me.)

[scottmcm]

Since this is opening up something new, could we fix #90435 & #90435 for this case as part of this change?

(Fixing those issues for existing code is harder, but if they didn't compile before maybe we can do it here?)

[fmease]

I've opened #115439 to fix #90435.

[RalfJung]

Since this is opening up something new, could we fix #90435 & #90435 for this case as part of this change?

I'm not sure if this has to be entangled with rustdoc changes. That's an entirely orthogonal discussion IMO.

[scottmcm]

We discussed this briefly in the lang triage meeting today, and the meeting was in agreement that the previous FCP applies, and that we're happy to see this addressed.

[RalfJung]

@TaKO8Ki the ball is in your court then. :)

[RalfJung]

This has lang team approval so for the review I suppose it's a t-compiler job.
r? compiler

[compiler-errors]

LGTM

@bors r+

[bors]

📌 Commit a6ccd26 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit a6ccd26 with merge 203c57d...

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 203c57d to master...

[rust-timer]

Finished benchmarking commit (203c57d): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.4%	[-2.4%, -2.4%]	1
Improvements ✅ (secondary)	-3.1%	[-3.4%, -2.9%]	2
All ❌✅ (primary)	-2.4%	[-2.4%, -2.4%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 635.505s -> 634.064s (-0.23%)
Artifact size: 318.39 MiB -> 318.47 MiB (0.02%)