Stabilize const ptr::write* and mem::replace

[workingjubilee]

Since const_mut_refs and const_refs_to_cell have been stabilized, we may now also stabilize the ability to write to places during const evaluation inside our library API. So, we now propose the const fn version of ptr::write and its variants. This allows us to also stabilize mem::replace and ptr::replace.

• const mem::replace: Tracking Issue for const_replace #83164 (comment)
• const ptr::write{,_bytes,_unaligned}: Tracking Issue for const_ptr_write #86302 (comment)

Their implementation requires an additional internal stabilization of const_intrinsic_forget, which is required for *::write* and thus *::replace. Thus we const-stabilize the internal intrinsics forget, write_bytes, and write_via_move.

• Closes Tracking Issue for const_replace #83164
• Closes Tracking Issue for const_ptr_write #86302

[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

[workingjubilee]

Note that because the replace stabilization requires the write stabilization in its current implementation, these cannot really land sooner than "all together" even though mem::replace entered FCP earlier, on the 21st.

Also note that there are already existing PRs for most of the slice-related API, so I did not attempt to include any of them except the one that can be expressed via slice syntax: the rest have even harsher dependency orderings.

I will revise this PR appropriately if any of the FCPs garners objections.

[workingjubilee]

cc @rust-lang/wg-const-eval As described in the PR message, the const_intrinsic_forget stabilization is part of the dependency chain for const_ptr_write and thus const_replace, and I believe this requires your approval. It's internal-only so it should not exactly be a big deal here.

[RalfJung]

There's in fact 3 intrinsics marked as const-stable here (meaning they are indirectly exposed to stable const code), which needs wg-const-eval approval, and t-lang should be in the loop as well:

• forget
• write_via_move
• write_bytes

None of them do anything odd. In fact forget does nothing at all; the other two just copy some bytes around -- basic stuff we can confidently commit const-eval to support. The implementation of these has been battle-tested in Miri.

@rust-lang/lang this should be an easy one.

[workingjubilee]

Ah, I figured the const_ptr_write ones went without saying.

[RalfJung]

It's not clear at all from the stable library surface whether new intrinsics are involved. :)

[bors]

☔ The latest upstream changes (presumably #130964) made this pull request unmergeable. Please resolve the merge conflicts.

[RalfJung]

@workingjubilee is there a reason #111774 is not included in this PR?

[traviscross]

@rfcbot fcp merge

[rfcbot]

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

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @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.

[tgross35]

There is some interest in having some of these APIs available at the same time as const_mut_refs #83164 (comment). Unfortunately the merge cutoff is October 11th, which is 10 days from today. Would it be acceptable to merge this on the 10th/11th as long as lang FCP has started, even if it has not completed?

Considering libs-api already has complete or near-complete FCPs for these and lang already completed the FCP for const_mut_refs, it seems less like this is a decision point and more like a lang ack that we are exposing API related to const mutability. (I could be missing something here)

[RalfJung]

IMO we should just merge what's FCP'd until then. We can let everything that needs the intrinsics slip to the next release. (That's just const_replace and const_ptr_write, I think?)

[tgross35]

Ah, I did not realize that the lang FCP was related to the intrinsics, thanks for the clarification. Your suggestion sounds reasonable.

[scottmcm]

@rfcbot reviewed

Agreed there's nothing lang-concerning here. write_via_move can already be written without features on nightly using copy_nonoverlapping, for example, so isn't exposing anything new.

[nikomatsakis]

@rfcbot reviewed

Sounds reasonable to me.

[rfcbot]

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

[tmandry]

@rfcbot reviewed

[traviscross]

@rustbot labels -I-lang-nominated

We discussed this in the meeting today... and it's now in FCP.

[workingjubilee]

Pursuant to my original remarks about modifying this PR if necessary as the FCPs it depends on develops, and to @tgross35's concern, I am going to chop this down to "stabilizations that depend on this T-lang FCP" and extract the quotient into a new PR: #131177

[bors]

☔ The latest upstream changes (presumably #131269) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #131275) made this pull request unmergeable. Please resolve the merge conflicts.