Clean up "const_hack" PRs now that const if/match exists

[oli-obk]

Before we had branches in const fn we added a few hacks to some functions by rewriting them in unreadable ways or removing assertions. We should undo all these hacks. The list of PRs with const hacks is https://github.com/rust-lang/rust/issues?q=label%3Aconst-hack+is%3Aclosed

Most of the time you'll want to revert the diff to the body of any const fn but not undo any other changes that these PRs made. Then you'll need to add allow_internal_unstable attributes for the const_if feature gate (or whatever other feature gates the compiler tells you to add) in case the const fn is already stable.

This issue has been assigned to @jumbatm via this comment.

[oli-obk]

cc @ecstatic-morse @RalfJung

[jumbatm]

Hi, may I give this a go?

@rustbot claim

[oli-obk]

It's all yours! Let me know if you run into any troubles or need more info.

[jumbatm]

Hello! I'm having a bit of trouble cleaning up the functions in num. Specifically, I'm getting num::<impl i8>::wrapping_abs is not yet stable as a const fn`, which I'm not sure how to solve, on the changes in this commit here jumbatm@a58d811.

I started by reverting the body of wrapping_abs to the pre-const-hack contents, and then adding the rustc_const_unstable annotation to the function. However, the compiler complained with the following message:

  src/libcore/num/mod.rs|1791 col 18 error 723| can only call other `const fn` within a `const fn`, but `const num::<impl i8>::wrapping_abs` is not stable as `const fn` 

To me, it seemed because overflowing_abs calls wrapping_abs, and I had just made wrapping_abs const unstable, I needed to mark overflowing_abs as const unstable too. So, I did so, but this only changed the error message:

src/libcore/num/mod.rs|1791 col 18 error| `num::<impl i8>::wrapping_abs` is not yet stable as a const fn

At this point, I reverted marking overflowing_abs as unstable, and checked the implementation of the check which was raising the error, and found it in qualify_min_const_fn:333. I saw this calls TyCtxt::is_const_fn(..), so I checked its implementation in src/librustc/ty/constness.rs:42, and saw rustc_const_unstable functions don't need to conform to min_const_fn.

Looking at the codebase, I saw there exists examples of other const unstable function which are able to call other rustc_const_unstable functions without issue -- for example, to_be_bytes (here), and it appears that propagating the rustc_const_unstable annotation to its callers is, indeed, the right thing to do.

So, I tried marking overflowing_abs as const unstable again, and this time looked at the check which was causing the "is not yet stable as a const fn" message, which I found in src/librustc_mir/transform/check_consts/op.rs:115. Due to my annotation, the error message suggests that I add #![feature(const_if_match)] to the crate, but you can see I already added it to libcore/lib.rs.
For some time, I thought FnCallUnstable from the same file was missing an override of fn feature_gate(...), that would look for feature, but realised because feature_gate is an associated function, I wouldn't be able to pass the instance-specific feature in anyway, and because this error isn't appearing for any other const unsafe code, the feature flag must have been handled somewhere earlier. I started looking for this in libsyntax/feature_gate, before realising this is probably a case where I should ask for help.

What's the (likely obvious 😝 ) detail I'm missing here that's causing this issue?

[oli-obk]

What's the (likely obvious stuck_out_tongue_closed_eyes ) detail I'm missing here that's causing this issue?

rustc_const_stable may never be changed to rustc_const_unstable, that would be a breaking change. If you want to use unstable features in a stable const fn, you need to add a new attribute: allow_internal_unstable(feature_gate_name) (this attribute also takes a comma separated list of feature gates if you need multiple ones

[oli-obk]

I adjusted the main post, sorry about that misinformation

[jumbatm]

Ahh, you're all good :) Thanks!