Shouldn't the black_box be the inner call?

Either way, the behavior is unspecified, even without black_box. imo I think it being outside the call makes more sense since it conveys better that optimizations may change the result, while calling is_val_statically_known on black_box may return false because it's a function call, or smth.

What about entirely removing black_box from the example?

Sounds good

Both doc tests fail when ran with ./x test core --stage 1 --doc -- is_val_statically_known. The doc tests are never ran with --stage 0 because of #[cfg(not(bootstrap())].

You need to add unsafe, use, and feature statements to make them compile. If you think they should be omitted from the docs, then you can prepend them with #.

Here is an example that passes the tests:

  /// ```rust
  /// #![feature(is_val_statically_known)]
  /// #![feature(core_intrinsics)]
  /// use std::hint::unreachable_unchecked;
  /// use std::intrinsics::is_val_statically_known;
  ///
  /// unsafe {
  ///    if !is_val_statically_known(0) { unreachable_unchecked(); }
  /// }
  /// ```
  ///
  /// This also means that the following code's behavior is unspecified; it
  /// may panic, or it may not:
  ///
  /// ```rust,no_run
  /// #![feature(is_val_statically_known)]
  /// #![feature(core_intrinsics)]
  /// use std::hint::black_box;
  /// use std::intrinsics::is_val_statically_known;
  ///
  /// unsafe {
  ///     assert_eq!(is_val_statically_known(0), black_box(is_val_statically_known(0)));
  /// }
  /// ```

Are they allowed to differ in panics? E.g. if an invalid input is handed to a safe function then it may either panic or return garbage and this differs between the branches?

Adding onto this, are panic messages/locations allowed to differ (if it always panics with the same inputs in CTFE/runtime)? They do in pow.

I'd say they must either both panic or neither panic. But the exact panic location is not relevant.

That should be documented then. Though I think it might be tricky to uphold. Would it be possible to have is_val_statically_known to always stick to one value in const eval? That would be less footgun-ish.

we could (in debug mode?) fork the const evaluator and run both paths and compare the result 🙃

That should be documented then. Though I think it might be tricky to uphold. Would it be possible to have is_val_statically_known to always stick to one value in const eval? That would be less footgun-ish.

It's the same with const_eval_select. We already have an RFC up for resolving this properly; in the mean time I think we should keep the strict rules.

They do in pow.

Could #[track_caller] and custom panic messages fix this? For that matter, is there a reason pow didn't have #[track_caller] to start out with?

Don't think there's any reason not to. Custom panic messages would be a nice addition also

I want to add, for the benefit of those reading in the future, that the core library already intentionally gives different panic messages depending on const_eval_select. It appears this is for performance reasons because the runtime variant is static, while the compile time variant is not. As far as I know, that is the only current use of const_eval_select.

It's used for a couple other things as well, like having certain assertions only in the run-time version of some low-level functions (assert_unsafe_precondition), and const-ifying functions whose runtime panic message needs the formatting machinery which is not supported at compile-time.

What is forget okay here? Does the real intrinsic also forget its argument? Should we restrict it to Copy types to avoid the confusion that could cause?

Copy is fine. This is cfg(bootstrap) so it should be gone by the next beta release anyway.

yea that may be better actually ^^ We don't support anything else in the backend anyway

Should be Copy on both of them then.

is incorrect to use #[cfg(debug_assertions)] here. In general, we can't assume debug_assertions matches overflow_checks even though they go together by default. This is especially true because this function has the #[rustc_inherit_overflow_checks].

Without #[cfg(debug_assertions)], it is still incomplete because the greatest possible u32 is much greater than the number of bits in an integer.

To correctly check for overflow, test to see if the final result is less than 1. If that is the case use _ = <Self>::MAX * <Self>::MAX; to force a panic iff overflow_checks are enabled.

Although it isn't necessary, you can make the code less verbose by using saturating_mul instead of overflowing_mul and by using (1 as Self).checked_shl().unwrap_or_default() instead of (1 << num_shl) * fine as Self.

just a nit to make it visually more clear that these are all together testing one thing

EDIT: hm I tried to remove the empty line, not sure if github supports that...