refactor 'valid for read/write' definition: exclude null

[RalfJung]

This is an attempt to resolve #138351.

The underlying problem is that when we decided to allow reads/writes/copies of size 0 even for null pointers, we documented that by changing the definition of "valid for read/write" in the standard library to say that null pointers are valid for 0-sized reads/writes. Unfortunately, that definition is also used in other places that assume that a valid-for-read/write pointer can be converted into a reference, and of course that's UB if the pointer is null, even if the pointee is a ZST.

The proposal for fixing this is to make "valid for reads/writes" slightly weaker than it has to be, and require the pointer to be non-null, and then to add exceptions to the most basic functions (read/write/copy) to explicitly allow arbitrary pointers when the size is 0. This isn't pretty but it's the best solution that has been suggested so far I think.

Cc @rust-lang/opsem @rust-lang/libs-api

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @scottmcm, libs
• @scottmcm, libs expanded to 8 candidates
• Random selection from Mark-Simulacrum, ibraheemdev, joboet, scottmcm

[Amanieu]

@rfcbot merge libs-api

[rust-rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @the8472

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.

[Amanieu]

This seemed fine to people in the libs-api meeting. Feel free to restart the FCP if you think that opsem also wants a say.

[RalfJung]

I think the opsem rules are clear, it's "just" a question of how to best document them in the context of how they are exposed in the library.

[rust-rfcbot]

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

[Mark-Simulacrum]

r=me with FCP done

@rustbot author

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[RalfJung]

I have updated this to include #149169: ptr::replace now also documents that null is allowed if T is a ZST.

[CAD97]

Just noting as a drive-by from another opsem member that this is of no impact to opsem, only how we surface it in documentation.

Furthermore, zero sized accesses are special cased at the opsem level to not care about pointer provenance at all, so the opsem fundamentally has a definition of "valid for access" which for non-zero-sized accesses separate from that for zero-sized ones. We previously attempted to document this as a single "valid for reads/writes" property in user docs, and this change essentially just admits that zero-sized access doesn't read/write and documents that preexisting special case on pointer accesses directly.

View changes since this review