Move select_unpredictable to the hint module

[Amanieu]

There has been considerable discussion in both the ACP (rust-lang/libs-team#468) and tracking issue (#133962) about whether the bool::select_unpredictable method should be in core::hint instead.

I believe this is the right move for the following reasons:

• The documentation explicitly says that it is a hint, not a codegen guarantee.
• bool doesn't have a corresponding select method, and I don't think we should be adding one.
• This shouldn't be something that people reach for with auto-completion unless they specifically understand the interactions with branch prediction. Using conditional moves can easily make code slower by preventing the CPU from speculating past the condition due to the data dependency.
• Although currently core::hint only contains no-ops, this isn't a hard rule (for example unreachable_unchecked is a bit of a gray area). The documentation only status that the module contains "hints to compiler that affects how code should be emitted or optimized". This is consistent with what select_unpredictable does.

[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

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[Amanieu]

r? libs-api

[dtolnay]

Looks good. I agree with the rationale for the move, and also ready to stabilize, like you have suggested in #133962 (comment).

I wondered whether we are consistent about whether to pub use intrinsics in their stable location, or whether to wrap like in this PR, but we seem to do it both ways.

rust/library/core/src/mem/mod.rs

Lines 24 to 26 in ae06b79

	#[stable(feature = "rust1", since = "1.0.0")]
	#[doc(inline)]
	pub use crate::intrinsics::transmute;

rust/library/core/src/ptr/mod.rs

Lines 408 to 416 in ae06b79

	#[stable(feature = "rust1", since = "1.0.0")]
	#[doc(inline)]
	pub use crate::intrinsics::copy;
	#[stable(feature = "rust1", since = "1.0.0")]
	#[doc(inline)]
	pub use crate::intrinsics::copy_nonoverlapping;
	#[stable(feature = "rust1", since = "1.0.0")]
	#[doc(inline)]
	pub use crate::intrinsics::write_bytes;

rust/library/core/src/hint.rs

Lines 473 to 478 in ae06b79

	#[inline]
	#[stable(feature = "bench_black_box", since = "1.66.0")]
	#[rustc_const_stable(feature = "const_black_box", since = "1.86.0")]
	pub const fn black_box<T>(dummy: T) -> T {
	crate::intrinsics::black_box(dummy)
	}

[dtolnay]

@bors r+

[bors]

📌 Commit 5d90ccb has been approved by dtolnay

It is now in the queue for this repository.

[RalfJung]

I wondered whether we are consistent about whether to pub use intrinsics in their stable location, or whether to wrap like in this PR, but we seem to do it both ways.

There's a difference between the two: pub used intrinsics cannot be turned into function pointers. AFAIK the only intrinsic we pub use these days is transmute since there it is required for the size check.

Note that intrinsics::copy etc that you cite are not the intrinsics, they are functions wrapping the intrinsic. Making them direct intrinsic re-exports again would be a breaking change due to the fn ptr issue, and making only the items in core::intrinsics actually be intrinsics would still be a breaking change as those paths are accidentally stable since the compiler used to not enforce stability on every path component.

[RalfJung]

This should probably say "cryptographic constant-time"; the term "constant-time" also often refers to algorithms that run in O(1). Sadly two CS sub-communities picked the same term for different concepts and both are very widely used.