nail down the final validity rules: references and unions

[RalfJung]

This translates the following t-opsem FCPs into Reference text:

• Should validity of a reference depend on the *contents* of memory in any way? unsafe-code-guidelines#414 (comment)
• Can references to uninhabited types ever be valid? unsafe-code-guidelines#413 (comment)
• What are the values of a union type? (in particular, what is the validity invariant of a union) unsafe-code-guidelines#438 (comment)

Cc @rust-lang/opsem

@rust-lang/lang you have not FCP'd this yet; please let us know if you want this to go through your own decision process as well.

Fixes rust-lang/unsafe-code-guidelines#413
Fixes rust-lang/unsafe-code-guidelines#414
Fixes rust-lang/unsafe-code-guidelines#438

[RalfJung]

@rustbot label +I-lang-nominated

[RalfJung]

A proposal came up in rust-lang/unsafe-code-guidelines#620 to slightly strengthen the requirements for references / Box to types with a slice tail.

@scottmcm do you have suggestions for how that should be worded?

[RalfJung]

These two lines are for rust-lang/unsafe-code-guidelines#620. We didn't explicitly discuss this case in the opsem FCP.

View changes since the review

[scottmcm]

do you have suggestions for how that should be worded?

I don't have anything concrete.

At least as a mental model -- whether it can be phrased well for a reference I'm less sure -- I wonder if there's a general rule here like saying that the type in the reference must, including looking at the metadata, represent a well-formed and inhabited type. (Part of me wants to say it comes from an unsizing, but there's nothing to unsize to a struct Foo(u32, [f64]); kind of thing, so I don't think that works, but maybe someone can come up with a cleverer phrasing.)

Basically I wish the "length has to be zero for uninhabited elements" and "length bound for non-ZST elements is usize::MAX / sizeof(T)" kinds of things were just corollaries of the general rule, to avoid things like the rust-lang/unsafe-code-guidelines#620 (comment) concern.

[RalfJung]

So what do you think about the wording I put in this PR?

[traviscross]

Thanks @RalfJung. We talked about this in the lang meeting and agreed we'd expect a lang FCP here if we're changing the language.

@rfcbot fcp merge lang

(Eliding opsem here as it's already been FCPed by the opsem team.)

[rust-rfcbot]

@traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

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!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[joshtriplett]

I reviewed the proposed rules both for unions and for references, and this looks reasonable to me.

@rfcbot reviewed

[scottmcm]

This makes me want a separate language construct for "no, I'm not doing partial overwrite silliness" because this rule has meant that unions are not usable for the cases I wanted, but if this is the right answer for FFI unions and such then so be it.

@rfcbot reviewed

[rust-rfcbot]

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

[RalfJung]

(Eliding opsem here as it's already been FCPed by the opsem team.)

FWIW the unsized type part hasn't been FCP'd by us yet, as mentioned above. We can do that in a separate issue or a joint FCP here.