stabilize const_cell_into_inner

[RalfJung]

This const-stabilizes

• UnsafeCell::into_inner
• Cell::into_inner
• RefCell::into_inner
• OnceCell::into_inner

@rust-lang/wg-const-eval this uses rustc_allow_const_fn_unstable(const_precise_live_drops), so we'd be comitting to always finding some way to accept this code. IMO that's fine -- what these functions do is to move out the only field of a struct, and that struct has no destructor itself. The field's destructor does not get run as it gets returned to the caller.

@rust-lang/libs-api this was FCP'd already years ago, except that OnceCell::into_inner was added to the same feature gate since then (Cc @tgross35). Does that mean we have to re-run the FCP? If yes, I'd honestly prefer to move OnceCell into its own feature gate to not risk missing the next release. (That's why it's not great to add new functions to an already FCP'd feature gate.) OTOH if this needs an FCP either way since the previous FCP was so long ago, then we might as well do it all at once.

[rustbot]

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
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

[RalfJung]

Seems to be something with cranelift?

  [PATCH] "stdlib" <- "0027-stdlib-128bit-atomic-operations.patch"
  error: patch failed: library/core/src/cell.rs:2246
  error: library/core/src/cell.rs: patch does not apply
  hint: Use 'git am --show-current-patch=diff' to see the failed patch
  Patch failed at 0001 Disable 128bit atomic operations

Cc @bjorn3

[tgross35]

@rust-lang/libs-api this was FCP'd already years ago, except that OnceCell::into_inner was added to the same feature gate since then (Cc @tgross35). Does that mean we have to re-run the FCP? If yes, I'd honestly prefer to move OnceCell into its own feature gate to not risk missing the next release. (That's why it's not great to add new functions to an already FCP'd feature gate.) OTOH if this needs an FCP either way since the previous FCP was so long ago, then we might as well do it all at once.

The OnceCell function signature is already stable, constness only makes use of UnsafeCell::into_inner which is under the same gate - it seemed entirely reasonable to keep the features together since libs-api needs to revisit the FCP in any case (and aiui, small adjustments to complete FCPs can happen with only consensus). But yes, if it is problematic then it can be split off.

[dtolnay]

I would be happy to approve this including OnceCell::into_inner. I don't think another separate FCP is warranted.

Seems to be something with cranelift?

Please try deleting these lines:

rust/compiler/rustc_codegen_cranelift/patches/0027-stdlib-128bit-atomic-operations.patch

Lines 85 to 97 in a1fd235

	diff --git a/library/core/src/cell.rs b/library/core/src/cell.rs
	index 58b9ba4..91bbd0a 100644
	--- a/library/core/src/cell.rs
	+++ b/library/core/src/cell.rs
	@@ -2246,8 +2246,6 @@ unsafe_cell_primitive_into_inner! {
	u32 "32"
	i64 "64"
	u64 "64"
	- i128 "128"
	- u128 "128"
	isize "ptr"
	usize "ptr"
	}

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[dtolnay]

@bors r+

[bors]

📌 Commit e1c09ec has been approved by dtolnay

It is now in the queue for this repository.