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}