Change:
Per comment by only supports primitive types - which is not listed anywhere in the documentation. When trying to use inside the core library on , compiler crashes . CC: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-contributor-roadblock +F-core_intrinsics +T-libs +T-compiler -needs-triage
Fixed in , building on nightly will fix this crash. also returns false for non primitive types since that PR.
In my opinion, I think that is more of a reason to update documentation.
claim
In terms of provenance and Miri, what does do with s? I want to explain it by stating that two code snippets are equivalent, but I don't know if it would be correct to use or . I think from a theoretical perspective, would be the way to go because the address is never being turned back into a , but I have no idea if Miri knows that.
In terms of the spec, just returns an arbitrary boolean, so pointer vs non-pointer doesn't really make any difference. So it's really up to the optimizer to decide whether knowing the address but not the provenance of a pointer is sufficient to consider the value "known". I personally would say "no", but it's always okay to return from this function so nothing can break if the answer becomes "yes". I don't know what LLVM does.
LLVM either: only considers the raw byte value of the pointer, or only considers the address of the pointer. I'm not sure, but I'd bet on the first. The potential difference between those two possibilities is explained in the docs for and . (I suspect the docs for is currently incorrect.)
There's no difference between those (on targets we currently support). If you think the docs are incorrect, please file an issue. Anyway, we can just call the version of the LLVM intrinsic, and worry about what it does once we actually need this on pointers somewhere.

Discussion:
/// particular value, ever. However, the compiler will generally make it /// return `true` only if the value of the argument is actually known. /// <del> /// When calling this in a `const fn`, both paths must be semantically /// equivalent, that is, the result of the `true` branch and the `false` /// branch must return the same value and have the same side-effects *no /// matter what*. </del> <ins> /// # Stability concerns /// /// While it is safe to call, this intrinsic may behave differently in /// a `const` context than otherwise. See the [`const_eval_select`] /// documentation for an explanation of the issues this can cause. Unlike /// `const_eval_select`, this intrinsic isn't guaranteed to behave /// deterministically even in a `const` context. /// /// # Type Requirements /// /// `T` must be either a `bool`, a `char`, a primitive numeric type (e.g. `f32`, /// but not `NonZeroISize`), or any thin pointer (e.g. `*mut String`). /// Any other argument types *may* cause a compiler error. /// /// ## Pointers /// /// When the input is a pointer, only the pointer itself is /// ever considered. The pointee has no effect. Currently, these functions /// behave identically: /// /// ``` /// #![feature(is_val_statically_known)] /// #![feature(core_intrinsics)] /// # #![allow(internal_features)] /// #![feature(strict_provenance)] /// use std::intrinsics::is_val_statically_known; /// /// fn foo(x: &i32) -> bool { ///     is_val_statically_known(x) /// } /// /// fn bar(x: &i32) -> bool { ///     is_val_statically_known( ///         (x as *const i32).addr() ///     ) /// } /// # _ = foo(&5_i32); /// # _ = bar(&5_i32); /// ``` </ins> #[rustc_const_unstable(feature = "is_val_statically_known", issue = "none")] #[rustc_nounwind] #[unstable(feature = "core_intrinsics", issue = "none")]