PhantomData layout guarantees

[joshlf]

No description provided.

[rustbot]

r? @Mark-Simulacrum

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

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[joshlf]

@rustbot label +T-libs-api -T-libs

[Mark-Simulacrum]

The documentation already guarantees in the first sentence that PhantomData is a ZST. I'm going to r? libs-api though for a double check, I personally don't think we necessarily need an FCP here (more of a clarification rather than new surface area IMO).

[joshlf]

Thanks for the quick reply!

The documentation already guarantees in the first sentence that PhantomData is a ZST.

Is your concern that this documentation is redundant, or are you just clarifying why this doesn't require FCP?

In either case, it's worth calling out that the alignment guarantee is new AFAICT. A ZST can have alignment > 1.

[Mark-Simulacrum]

No, only the first line about size is redundant (but also fine and reasonable to have together like this).

In practice I think the ask for no alignment changes to phantomdata feels new but not really, since changing it would probably break expectations anyway.

[ChrisDenton]

Would #[repr(align(...))] not be shown in the generated docs?

[joshlf]

Would #[repr(align(...))] not be shown in the generated docs?

repr(align(...)) only provides a lower bound, not an upper bound, so it's a moot point. That said, there's also no agreement about which attributes are considered part of a type's API. For example, the Wrapping type is defined as:

#[repr(transparent)]
pub struct Wrapping<T>(pub T);

...and yet, there's still a "Layout" section which documents what guarantees are made about Wrapping's layout.

[m-ou-se]

The 'align == 1' part is new to this documentation, so let's do an FCP to be sure.

@rfcbot merge

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[dtolnay]

@bors r+ rollup

[bors]

📌 Commit 72a9029 has been approved by dtolnay

It is now in the queue for this repository.