core/hint.rs
1#![stable(feature = "core_hint", since = "1.27.0")]
2
3//! Hints to compiler that affects how code should be emitted or optimized.
4//!
5//! Hints may be compile time or runtime.
6
7#[cfg(not(feature = "ferrocene_certified"))]
8use crate::mem::MaybeUninit;
9use crate::{intrinsics, ub_checks};
10
11/// Informs the compiler that the site which is calling this function is not
12/// reachable, possibly enabling further optimizations.
13///
14/// # Safety
15///
16/// Reaching this function is *Undefined Behavior*.
17///
18/// As the compiler assumes that all forms of Undefined Behavior can never
19/// happen, it will eliminate all branches in the surrounding code that it can
20/// determine will invariably lead to a call to `unreachable_unchecked()`.
21///
22/// If the assumptions embedded in using this function turn out to be wrong -
23/// that is, if the site which is calling `unreachable_unchecked()` is actually
24/// reachable at runtime - the compiler may have generated nonsensical machine
25/// instructions for this situation, including in seemingly unrelated code,
26/// causing difficult-to-debug problems.
27///
28/// Use this function sparingly. Consider using the [`unreachable!`] macro,
29/// which may prevent some optimizations but will safely panic in case it is
30/// actually reached at runtime. Benchmark your code to find out if using
31/// `unreachable_unchecked()` comes with a performance benefit.
32///
33/// # Examples
34///
35/// `unreachable_unchecked()` can be used in situations where the compiler
36/// can't prove invariants that were previously established. Such situations
37/// have a higher chance of occurring if those invariants are upheld by
38/// external code that the compiler can't analyze.
39/// ```
40/// fn prepare_inputs(divisors: &mut Vec<u32>) {
41/// // Note to future-self when making changes: The invariant established
42/// // here is NOT checked in `do_computation()`; if this changes, you HAVE
43/// // to change `do_computation()`.
44/// divisors.retain(|divisor| *divisor != 0)
45/// }
46///
47/// /// # Safety
48/// /// All elements of `divisor` must be non-zero.
49/// unsafe fn do_computation(i: u32, divisors: &[u32]) -> u32 {
50/// divisors.iter().fold(i, |acc, divisor| {
51/// // Convince the compiler that a division by zero can't happen here
52/// // and a check is not needed below.
53/// if *divisor == 0 {
54/// // Safety: `divisor` can't be zero because of `prepare_inputs`,
55/// // but the compiler does not know about this. We *promise*
56/// // that we always call `prepare_inputs`.
57/// unsafe { std::hint::unreachable_unchecked() }
58/// }
59/// // The compiler would normally introduce a check here that prevents
60/// // a division by zero. However, if `divisor` was zero, the branch
61/// // above would reach what we explicitly marked as unreachable.
62/// // The compiler concludes that `divisor` can't be zero at this point
63/// // and removes the - now proven useless - check.
64/// acc / divisor
65/// })
66/// }
67///
68/// let mut divisors = vec![2, 0, 4];
69/// prepare_inputs(&mut divisors);
70/// let result = unsafe {
71/// // Safety: prepare_inputs() guarantees that divisors is non-zero
72/// do_computation(100, &divisors)
73/// };
74/// assert_eq!(result, 12);
75///
76/// ```
77///
78/// While using `unreachable_unchecked()` is perfectly sound in the following
79/// example, as the compiler is able to prove that a division by zero is not
80/// possible, benchmarking reveals that `unreachable_unchecked()` provides
81/// no benefit over using [`unreachable!`], while the latter does not introduce
82/// the possibility of Undefined Behavior.
83///
84/// ```
85/// fn div_1(a: u32, b: u32) -> u32 {
86/// use std::hint::unreachable_unchecked;
87///
88/// // `b.saturating_add(1)` is always positive (not zero),
89/// // hence `checked_div` will never return `None`.
90/// // Therefore, the else branch is unreachable.
91/// a.checked_div(b.saturating_add(1))
92/// .unwrap_or_else(|| unsafe { unreachable_unchecked() })
93/// }
94///
95/// assert_eq!(div_1(7, 0), 7);
96/// assert_eq!(div_1(9, 1), 4);
97/// assert_eq!(div_1(11, u32::MAX), 0);
98/// ```
99#[inline]
100#[stable(feature = "unreachable", since = "1.27.0")]
101#[rustc_const_stable(feature = "const_unreachable_unchecked", since = "1.57.0")]
102#[track_caller]
103#[coverage(off)] // Ferrocene addition: this function breaks llvm-cov
104pub const unsafe fn unreachable_unchecked() -> ! {
105 ub_checks::assert_unsafe_precondition!(
106 check_language_ub,
107 "hint::unreachable_unchecked must never be reached",
108 () => false
109 );
110 // SAFETY: the safety contract for `intrinsics::unreachable` must
111 // be upheld by the caller.
112 unsafe { intrinsics::unreachable() }
113}
114
115/// Makes a *soundness* promise to the compiler that `cond` holds.
116///
117/// This may allow the optimizer to simplify things, but it might also make the generated code
118/// slower. Either way, calling it will most likely make compilation take longer.
119///
120/// You may know this from other places as
121/// [`llvm.assume`](https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic) or, in C,
122/// [`__builtin_assume`](https://clang.llvm.org/docs/LanguageExtensions.html#builtin-assume).
123///
124/// This promotes a correctness requirement to a soundness requirement. Don't do that without
125/// very good reason.
126///
127/// # Usage
128///
129/// This is a situational tool for micro-optimization, and is allowed to do nothing. Any use
130/// should come with a repeatable benchmark to show the value, with the expectation to drop it
131/// later should the optimizer get smarter and no longer need it.
132///
133/// The more complicated the condition, the less likely this is to be useful. For example,
134/// `assert_unchecked(foo.is_sorted())` is a complex enough value that the compiler is unlikely
135/// to be able to take advantage of it.
136///
137/// There's also no need to `assert_unchecked` basic properties of things. For example, the
138/// compiler already knows the range of `count_ones`, so there is no benefit to
139/// `let n = u32::count_ones(x); assert_unchecked(n <= u32::BITS);`.
140///
141/// `assert_unchecked` is logically equivalent to `if !cond { unreachable_unchecked(); }`. If
142/// ever you are tempted to write `assert_unchecked(false)`, you should instead use
143/// [`unreachable_unchecked()`] directly.
144///
145/// # Safety
146///
147/// `cond` must be `true`. It is immediate UB to call this with `false`.
148///
149/// # Example
150///
151/// ```
152/// use core::hint;
153///
154/// /// # Safety
155/// ///
156/// /// `p` must be nonnull and valid
157/// pub unsafe fn next_value(p: *const i32) -> i32 {
158/// // SAFETY: caller invariants guarantee that `p` is not null
159/// unsafe { hint::assert_unchecked(!p.is_null()) }
160///
161/// if p.is_null() {
162/// return -1;
163/// } else {
164/// // SAFETY: caller invariants guarantee that `p` is valid
165/// unsafe { *p + 1 }
166/// }
167/// }
168/// ```
169///
170/// Without the `assert_unchecked`, the above function produces the following with optimizations
171/// enabled:
172///
173/// ```asm
174/// next_value:
175/// test rdi, rdi
176/// je .LBB0_1
177/// mov eax, dword ptr [rdi]
178/// inc eax
179/// ret
180/// .LBB0_1:
181/// mov eax, -1
182/// ret
183/// ```
184///
185/// Adding the assertion allows the optimizer to remove the extra check:
186///
187/// ```asm
188/// next_value:
189/// mov eax, dword ptr [rdi]
190/// inc eax
191/// ret
192/// ```
193///
194/// This example is quite unlike anything that would be used in the real world: it is redundant
195/// to put an assertion right next to code that checks the same thing, and dereferencing a
196/// pointer already has the builtin assumption that it is nonnull. However, it illustrates the
197/// kind of changes the optimizer can make even when the behavior is less obviously related.
198#[track_caller]
199#[inline(always)]
200#[doc(alias = "assume")]
201#[stable(feature = "hint_assert_unchecked", since = "1.81.0")]
202#[rustc_const_stable(feature = "hint_assert_unchecked", since = "1.81.0")]
203#[cfg(not(feature = "ferrocene_certified"))]
204pub const unsafe fn assert_unchecked(cond: bool) {
205 // SAFETY: The caller promised `cond` is true.
206 unsafe {
207 ub_checks::assert_unsafe_precondition!(
208 check_language_ub,
209 "hint::assert_unchecked must never be called when the condition is false",
210 (cond: bool = cond) => cond,
211 );
212 crate::intrinsics::assume(cond);
213 }
214}
215
216/// Emits a machine instruction to signal the processor that it is running in
217/// a busy-wait spin-loop ("spin lock").
218///
219/// Upon receiving the spin-loop signal the processor can optimize its behavior by,
220/// for example, saving power or switching hyper-threads.
221///
222/// This function is different from [`thread::yield_now`] which directly
223/// yields to the system's scheduler, whereas `spin_loop` does not interact
224/// with the operating system.
225///
226/// A common use case for `spin_loop` is implementing bounded optimistic
227/// spinning in a CAS loop in synchronization primitives. To avoid problems
228/// like priority inversion, it is strongly recommended that the spin loop is
229/// terminated after a finite amount of iterations and an appropriate blocking
230/// syscall is made.
231///
232/// **Note**: On platforms that do not support receiving spin-loop hints this
233/// function does not do anything at all.
234///
235/// # Examples
236///
237/// ```ignore-wasm
238/// use std::sync::atomic::{AtomicBool, Ordering};
239/// use std::sync::Arc;
240/// use std::{hint, thread};
241///
242/// // A shared atomic value that threads will use to coordinate
243/// let live = Arc::new(AtomicBool::new(false));
244///
245/// // In a background thread we'll eventually set the value
246/// let bg_work = {
247/// let live = live.clone();
248/// thread::spawn(move || {
249/// // Do some work, then make the value live
250/// do_some_work();
251/// live.store(true, Ordering::Release);
252/// })
253/// };
254///
255/// // Back on our current thread, we wait for the value to be set
256/// while !live.load(Ordering::Acquire) {
257/// // The spin loop is a hint to the CPU that we're waiting, but probably
258/// // not for very long
259/// hint::spin_loop();
260/// }
261///
262/// // The value is now set
263/// # fn do_some_work() {}
264/// do_some_work();
265/// bg_work.join()?;
266/// # Ok::<(), Box<dyn core::any::Any + Send + 'static>>(())
267/// ```
268///
269/// [`thread::yield_now`]: ../../std/thread/fn.yield_now.html
270#[inline(always)]
271#[stable(feature = "renamed_spin_loop", since = "1.49.0")]
272#[cfg(not(feature = "ferrocene_certified"))]
273pub fn spin_loop() {
274 crate::cfg_select! {
275 target_arch = "x86" => {
276 // SAFETY: the `cfg` attr ensures that we only execute this on x86 targets.
277 unsafe { crate::arch::x86::_mm_pause() }
278 }
279 target_arch = "x86_64" => {
280 // SAFETY: the `cfg` attr ensures that we only execute this on x86_64 targets.
281 unsafe { crate::arch::x86_64::_mm_pause() }
282 }
283 target_arch = "riscv32" => crate::arch::riscv32::pause(),
284 target_arch = "riscv64" => crate::arch::riscv64::pause(),
285 any(target_arch = "aarch64", target_arch = "arm64ec") => {
286 // SAFETY: the `cfg` attr ensures that we only execute this on aarch64 targets.
287 unsafe { crate::arch::aarch64::__isb(crate::arch::aarch64::SY) }
288 }
289 all(target_arch = "arm", target_feature = "v6") => {
290 // SAFETY: the `cfg` attr ensures that we only execute this on arm targets
291 // with support for the v6 feature.
292 unsafe { crate::arch::arm::__yield() }
293 }
294 target_arch = "loongarch32" => crate::arch::loongarch32::ibar::<0>(),
295 target_arch = "loongarch64" => crate::arch::loongarch64::ibar::<0>(),
296 _ => { /* do nothing */ }
297 }
298}
299
300/// An identity function that *__hints__* to the compiler to be maximally pessimistic about what
301/// `black_box` could do.
302///
303/// Unlike [`std::convert::identity`], a Rust compiler is encouraged to assume that `black_box` can
304/// use `dummy` in any possible valid way that Rust code is allowed to without introducing undefined
305/// behavior in the calling code. This property makes `black_box` useful for writing code in which
306/// certain optimizations are not desired, such as benchmarks.
307///
308/// <div class="warning">
309///
310/// Note however, that `black_box` is only (and can only be) provided on a "best-effort" basis. The
311/// extent to which it can block optimisations may vary depending upon the platform and code-gen
312/// backend used. Programs cannot rely on `black_box` for *correctness*, beyond it behaving as the
313/// identity function. As such, it **must not be relied upon to control critical program behavior.**
314/// This also means that this function does not offer any guarantees for cryptographic or security
315/// purposes.
316///
317/// This limitation is not specific to `black_box`; there is no mechanism in the entire Rust
318/// language that can provide the guarantees required for constant-time cryptography.
319/// (There is also no such mechanism in LLVM, so the same is true for every other LLVM-based compiler.)
320///
321/// </div>
322///
323/// [`std::convert::identity`]: crate::convert::identity
324///
325/// # When is this useful?
326///
327/// While not suitable in those mission-critical cases, `black_box`'s functionality can generally be
328/// relied upon for benchmarking, and should be used there. It will try to ensure that the
329/// compiler doesn't optimize away part of the intended test code based on context. For
330/// example:
331///
332/// ```
333/// fn contains(haystack: &[&str], needle: &str) -> bool {
334/// haystack.iter().any(|x| x == &needle)
335/// }
336///
337/// pub fn benchmark() {
338/// let haystack = vec!["abc", "def", "ghi", "jkl", "mno"];
339/// let needle = "ghi";
340/// for _ in 0..10 {
341/// contains(&haystack, needle);
342/// }
343/// }
344/// ```
345///
346/// The compiler could theoretically make optimizations like the following:
347///
348/// - The `needle` and `haystack` do not change, move the call to `contains` outside the loop and
349/// delete the loop
350/// - Inline `contains`
351/// - `needle` and `haystack` have values known at compile time, `contains` is always true. Remove
352/// the call and replace with `true`
353/// - Nothing is done with the result of `contains`: delete this function call entirely
354/// - `benchmark` now has no purpose: delete this function
355///
356/// It is not likely that all of the above happens, but the compiler is definitely able to make some
357/// optimizations that could result in a very inaccurate benchmark. This is where `black_box` comes
358/// in:
359///
360/// ```
361/// use std::hint::black_box;
362///
363/// // Same `contains` function.
364/// fn contains(haystack: &[&str], needle: &str) -> bool {
365/// haystack.iter().any(|x| x == &needle)
366/// }
367///
368/// pub fn benchmark() {
369/// let haystack = vec!["abc", "def", "ghi", "jkl", "mno"];
370/// let needle = "ghi";
371/// for _ in 0..10 {
372/// // Force the compiler to run `contains`, even though it is a pure function whose
373/// // results are unused.
374/// black_box(contains(
375/// // Prevent the compiler from making assumptions about the input.
376/// black_box(&haystack),
377/// black_box(needle),
378/// ));
379/// }
380/// }
381/// ```
382///
383/// This essentially tells the compiler to block optimizations across any calls to `black_box`. So,
384/// it now:
385///
386/// - Treats both arguments to `contains` as unpredictable: the body of `contains` can no longer be
387/// optimized based on argument values
388/// - Treats the call to `contains` and its result as volatile: the body of `benchmark` cannot
389/// optimize this away
390///
391/// This makes our benchmark much more realistic to how the function would actually be used, where
392/// arguments are usually not known at compile time and the result is used in some way.
393///
394/// # How to use this
395///
396/// In practice, `black_box` serves two purposes:
397///
398/// 1. It prevents the compiler from making optimizations related to the value returned by `black_box`
399/// 2. It forces the value passed to `black_box` to be calculated, even if the return value of `black_box` is unused
400///
401/// ```
402/// use std::hint::black_box;
403///
404/// let zero = 0;
405/// let five = 5;
406///
407/// // The compiler will see this and remove the `* five` call, because it knows that multiplying
408/// // any integer by 0 will result in 0.
409/// let c = zero * five;
410///
411/// // Adding `black_box` here disables the compiler's ability to reason about the first operand in the multiplication.
412/// // It is forced to assume that it can be any possible number, so it cannot remove the `* five`
413/// // operation.
414/// let c = black_box(zero) * five;
415/// ```
416///
417/// While most cases will not be as clear-cut as the above example, it still illustrates how
418/// `black_box` can be used. When benchmarking a function, you usually want to wrap its inputs in
419/// `black_box` so the compiler cannot make optimizations that would be unrealistic in real-life
420/// use.
421///
422/// ```
423/// use std::hint::black_box;
424///
425/// // This is a simple function that increments its input by 1. Note that it is pure, meaning it
426/// // has no side-effects. This function has no effect if its result is unused. (An example of a
427/// // function *with* side-effects is `println!()`.)
428/// fn increment(x: u8) -> u8 {
429/// x + 1
430/// }
431///
432/// // Here, we call `increment` but discard its result. The compiler, seeing this and knowing that
433/// // `increment` is pure, will eliminate this function call entirely. This may not be desired,
434/// // though, especially if we're trying to track how much time `increment` takes to execute.
435/// let _ = increment(black_box(5));
436///
437/// // Here, we force `increment` to be executed. This is because the compiler treats `black_box`
438/// // as if it has side-effects, and thus must compute its input.
439/// let _ = black_box(increment(black_box(5)));
440/// ```
441///
442/// There may be additional situations where you want to wrap the result of a function in
443/// `black_box` to force its execution. This is situational though, and may not have any effect
444/// (such as when the function returns a zero-sized type such as [`()` unit][unit]).
445///
446/// Note that `black_box` has no effect on how its input is treated, only its output. As such,
447/// expressions passed to `black_box` may still be optimized:
448///
449/// ```
450/// use std::hint::black_box;
451///
452/// // The compiler sees this...
453/// let y = black_box(5 * 10);
454///
455/// // ...as this. As such, it will likely simplify `5 * 10` to just `50`.
456/// let _0 = 5 * 10;
457/// let y = black_box(_0);
458/// ```
459///
460/// In the above example, the `5 * 10` expression is considered distinct from the `black_box` call,
461/// and thus is still optimized by the compiler. You can prevent this by moving the multiplication
462/// operation outside of `black_box`:
463///
464/// ```
465/// use std::hint::black_box;
466///
467/// // No assumptions can be made about either operand, so the multiplication is not optimized out.
468/// let y = black_box(5) * black_box(10);
469/// ```
470///
471/// During constant evaluation, `black_box` is treated as a no-op.
472#[inline]
473#[stable(feature = "bench_black_box", since = "1.66.0")]
474#[rustc_const_stable(feature = "const_black_box", since = "1.86.0")]
475#[cfg(not(feature = "ferrocene_certified"))]
476pub const fn black_box<T>(dummy: T) -> T {
477 crate::intrinsics::black_box(dummy)
478}
479
480/// An identity function that causes an `unused_must_use` warning to be
481/// triggered if the given value is not used (returned, stored in a variable,
482/// etc) by the caller.
483///
484/// This is primarily intended for use in macro-generated code, in which a
485/// [`#[must_use]` attribute][must_use] either on a type or a function would not
486/// be convenient.
487///
488/// [must_use]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute
489///
490/// # Example
491///
492/// ```
493/// #![feature(hint_must_use)]
494///
495/// use core::fmt;
496///
497/// pub struct Error(/* ... */);
498///
499/// #[macro_export]
500/// macro_rules! make_error {
501/// ($($args:expr),*) => {
502/// core::hint::must_use({
503/// let error = $crate::make_error(core::format_args!($($args),*));
504/// error
505/// })
506/// };
507/// }
508///
509/// // Implementation detail of make_error! macro.
510/// #[doc(hidden)]
511/// pub fn make_error(args: fmt::Arguments<'_>) -> Error {
512/// Error(/* ... */)
513/// }
514///
515/// fn demo() -> Option<Error> {
516/// if true {
517/// // Oops, meant to write `return Some(make_error!("..."));`
518/// Some(make_error!("..."));
519/// }
520/// None
521/// }
522/// #
523/// # // Make rustdoc not wrap the whole snippet in fn main, so that $crate::make_error works
524/// # fn main() {}
525/// ```
526///
527/// In the above example, we'd like an `unused_must_use` lint to apply to the
528/// value created by `make_error!`. However, neither `#[must_use]` on a struct
529/// nor `#[must_use]` on a function is appropriate here, so the macro expands
530/// using `core::hint::must_use` instead.
531///
532/// - We wouldn't want `#[must_use]` on the `struct Error` because that would
533/// make the following unproblematic code trigger a warning:
534///
535/// ```
536/// # struct Error;
537/// #
538/// fn f(arg: &str) -> Result<(), Error>
539/// # { Ok(()) }
540///
541/// #[test]
542/// fn t() {
543/// // Assert that `f` returns error if passed an empty string.
544/// // A value of type `Error` is unused here but that's not a problem.
545/// f("").unwrap_err();
546/// }
547/// ```
548///
549/// - Using `#[must_use]` on `fn make_error` can't help because the return value
550/// *is* used, as the right-hand side of a `let` statement. The `let`
551/// statement looks useless but is in fact necessary for ensuring that
552/// temporaries within the `format_args` expansion are not kept alive past the
553/// creation of the `Error`, as keeping them alive past that point can cause
554/// autotrait issues in async code:
555///
556/// ```
557/// # #![feature(hint_must_use)]
558/// #
559/// # struct Error;
560/// #
561/// # macro_rules! make_error {
562/// # ($($args:expr),*) => {
563/// # core::hint::must_use({
564/// # // If `let` isn't used, then `f()` produces a non-Send future.
565/// # let error = make_error(core::format_args!($($args),*));
566/// # error
567/// # })
568/// # };
569/// # }
570/// #
571/// # fn make_error(args: core::fmt::Arguments<'_>) -> Error {
572/// # Error
573/// # }
574/// #
575/// async fn f() {
576/// // Using `let` inside the make_error expansion causes temporaries like
577/// // `unsync()` to drop at the semicolon of that `let` statement, which
578/// // is prior to the await point. They would otherwise stay around until
579/// // the semicolon on *this* statement, which is after the await point,
580/// // and the enclosing Future would not implement Send.
581/// log(make_error!("look: {:p}", unsync())).await;
582/// }
583///
584/// async fn log(error: Error) {/* ... */}
585///
586/// // Returns something without a Sync impl.
587/// fn unsync() -> *const () {
588/// 0 as *const ()
589/// }
590/// #
591/// # fn test() {
592/// # fn assert_send(_: impl Send) {}
593/// # assert_send(f());
594/// # }
595/// ```
596#[unstable(feature = "hint_must_use", issue = "94745")]
597#[must_use] // <-- :)
598#[inline(always)]
599#[cfg(not(feature = "ferrocene_certified"))]
600pub const fn must_use<T>(value: T) -> T {
601 value
602}
603
604/// Hints to the compiler that a branch condition is likely to be true.
605/// Returns the value passed to it.
606///
607/// It can be used with `if` or boolean `match` expressions.
608///
609/// When used outside of a branch condition, it may still influence a nearby branch, but
610/// probably will not have any effect.
611///
612/// It can also be applied to parts of expressions, such as `likely(a) && unlikely(b)`, or to
613/// compound expressions, such as `likely(a && b)`. When applied to compound expressions, it has
614/// the following effect:
615/// ```text
616/// likely(!a) => !unlikely(a)
617/// likely(a && b) => likely(a) && likely(b)
618/// likely(a || b) => a || likely(b)
619/// ```
620///
621/// See also the function [`cold_path()`] which may be more appropriate for idiomatic Rust code.
622///
623/// # Examples
624///
625/// ```
626/// #![feature(likely_unlikely)]
627/// use core::hint::likely;
628///
629/// fn foo(x: i32) {
630/// if likely(x > 0) {
631/// println!("this branch is likely to be taken");
632/// } else {
633/// println!("this branch is unlikely to be taken");
634/// }
635///
636/// match likely(x > 0) {
637/// true => println!("this branch is likely to be taken"),
638/// false => println!("this branch is unlikely to be taken"),
639/// }
640///
641/// // Use outside of a branch condition may still influence a nearby branch
642/// let cond = likely(x != 0);
643/// if cond {
644/// println!("this branch is likely to be taken");
645/// }
646/// }
647/// ```
648#[unstable(feature = "likely_unlikely", issue = "136873")]
649#[inline(always)]
650#[cfg(not(feature = "ferrocene_certified"))]
651pub const fn likely(b: bool) -> bool {
652 crate::intrinsics::likely(b)
653}
654
655/// Hints to the compiler that a branch condition is unlikely to be true.
656/// Returns the value passed to it.
657///
658/// It can be used with `if` or boolean `match` expressions.
659///
660/// When used outside of a branch condition, it may still influence a nearby branch, but
661/// probably will not have any effect.
662///
663/// It can also be applied to parts of expressions, such as `likely(a) && unlikely(b)`, or to
664/// compound expressions, such as `unlikely(a && b)`. When applied to compound expressions, it has
665/// the following effect:
666/// ```text
667/// unlikely(!a) => !likely(a)
668/// unlikely(a && b) => a && unlikely(b)
669/// unlikely(a || b) => unlikely(a) || unlikely(b)
670/// ```
671///
672/// See also the function [`cold_path()`] which may be more appropriate for idiomatic Rust code.
673///
674/// # Examples
675///
676/// ```
677/// #![feature(likely_unlikely)]
678/// use core::hint::unlikely;
679///
680/// fn foo(x: i32) {
681/// if unlikely(x > 0) {
682/// println!("this branch is unlikely to be taken");
683/// } else {
684/// println!("this branch is likely to be taken");
685/// }
686///
687/// match unlikely(x > 0) {
688/// true => println!("this branch is unlikely to be taken"),
689/// false => println!("this branch is likely to be taken"),
690/// }
691///
692/// // Use outside of a branch condition may still influence a nearby branch
693/// let cond = unlikely(x != 0);
694/// if cond {
695/// println!("this branch is likely to be taken");
696/// }
697/// }
698/// ```
699#[unstable(feature = "likely_unlikely", issue = "136873")]
700#[inline(always)]
701#[cfg(not(feature = "ferrocene_certified"))]
702pub const fn unlikely(b: bool) -> bool {
703 crate::intrinsics::unlikely(b)
704}
705
706/// Hints to the compiler that given path is cold, i.e., unlikely to be taken. The compiler may
707/// choose to optimize paths that are not cold at the expense of paths that are cold.
708///
709/// # Examples
710///
711/// ```
712/// #![feature(cold_path)]
713/// use core::hint::cold_path;
714///
715/// fn foo(x: &[i32]) {
716/// if let Some(first) = x.get(0) {
717/// // this is the fast path
718/// } else {
719/// // this path is unlikely
720/// cold_path();
721/// }
722/// }
723///
724/// fn bar(x: i32) -> i32 {
725/// match x {
726/// 1 => 10,
727/// 2 => 100,
728/// 3 => { cold_path(); 1000 }, // this branch is unlikely
729/// _ => { cold_path(); 10000 }, // this is also unlikely
730/// }
731/// }
732/// ```
733#[unstable(feature = "cold_path", issue = "136873")]
734#[inline(always)]
735#[cfg(not(feature = "ferrocene_certified"))]
736pub const fn cold_path() {
737 crate::intrinsics::cold_path()
738}
739
740/// Returns either `true_val` or `false_val` depending on the value of
741/// `condition`, with a hint to the compiler that `condition` is unlikely to be
742/// correctly predicted by a CPU’s branch predictor.
743///
744/// This method is functionally equivalent to
745/// ```ignore (this is just for illustrative purposes)
746/// fn select_unpredictable<T>(b: bool, true_val: T, false_val: T) -> T {
747/// if b { true_val } else { false_val }
748/// }
749/// ```
750/// but might generate different assembly. In particular, on platforms with
751/// a conditional move or select instruction (like `cmov` on x86 or `csel`
752/// on ARM) the optimizer might use these instructions to avoid branches,
753/// which can benefit performance if the branch predictor is struggling
754/// with predicting `condition`, such as in an implementation of binary
755/// search.
756///
757/// Note however that this lowering is not guaranteed (on any platform) and
758/// should not be relied upon when trying to write cryptographic constant-time
759/// code. Also be aware that this lowering might *decrease* performance if
760/// `condition` is well-predictable. It is advisable to perform benchmarks to
761/// tell if this function is useful.
762///
763/// # Examples
764///
765/// Distribute values evenly between two buckets:
766/// ```
767/// use std::hash::BuildHasher;
768/// use std::hint;
769///
770/// fn append<H: BuildHasher>(hasher: &H, v: i32, bucket_one: &mut Vec<i32>, bucket_two: &mut Vec<i32>) {
771/// let hash = hasher.hash_one(&v);
772/// let bucket = hint::select_unpredictable(hash % 2 == 0, bucket_one, bucket_two);
773/// bucket.push(v);
774/// }
775/// # let hasher = std::collections::hash_map::RandomState::new();
776/// # let mut bucket_one = Vec::new();
777/// # let mut bucket_two = Vec::new();
778/// # append(&hasher, 42, &mut bucket_one, &mut bucket_two);
779/// # assert_eq!(bucket_one.len() + bucket_two.len(), 1);
780/// ```
781#[inline(always)]
782#[stable(feature = "select_unpredictable", since = "1.88.0")]
783#[cfg(not(feature = "ferrocene_certified"))]
784pub fn select_unpredictable<T>(condition: bool, true_val: T, false_val: T) -> T {
785 // FIXME(https://github.com/rust-lang/unsafe-code-guidelines/issues/245):
786 // Change this to use ManuallyDrop instead.
787 let mut true_val = MaybeUninit::new(true_val);
788 let mut false_val = MaybeUninit::new(false_val);
789
790 struct DropOnPanic<T> {
791 // Invariant: valid pointer and points to an initialized value that is not further used,
792 // i.e. it can be dropped by this guard.
793 inner: *mut T,
794 }
795
796 impl<T> Drop for DropOnPanic<T> {
797 fn drop(&mut self) {
798 // SAFETY: Must be guaranteed on construction of local type `DropOnPanic`.
799 unsafe { self.inner.drop_in_place() }
800 }
801 }
802
803 let true_ptr = true_val.as_mut_ptr();
804 let false_ptr = false_val.as_mut_ptr();
805
806 // SAFETY: The value that is not selected is dropped, and the selected one
807 // is returned. This is necessary because the intrinsic doesn't drop the
808 // value that is not selected.
809 unsafe {
810 // Extract the selected value first, ensure it is dropped as well if dropping the unselected
811 // value panics. We construct a temporary by-pointer guard around the selected value while
812 // dropping the unselected value. Arguments overlap here, so we can not use mutable
813 // reference for these arguments.
814 let guard = crate::intrinsics::select_unpredictable(condition, true_ptr, false_ptr);
815 let drop = crate::intrinsics::select_unpredictable(condition, false_ptr, true_ptr);
816
817 // SAFETY: both pointers are well-aligned and point to initialized values inside a
818 // `MaybeUninit` each. In both possible values for `condition` the pointer `guard` and
819 // `drop` do not alias (even though the two argument pairs we have selected from did alias
820 // each other).
821 let guard = DropOnPanic { inner: guard };
822 drop.drop_in_place();
823 crate::mem::forget(guard);
824
825 // Note that it is important to use the values here. Reading from the pointer we got makes
826 // LLVM forget the !unpredictable annotation sometimes (in tests, integer sized values in
827 // particular seemed to confuse it, also observed in llvm/llvm-project #82340).
828 crate::intrinsics::select_unpredictable(condition, true_val, false_val).assume_init()
829 }
830}