Change:
#![feature(cfg_target_has_atomic)] #![feature(concat_idents)] #![feature(const_fn)] <ins> #![feature(const_if_match)] #![feature(const_panic)] </ins> #![feature(const_fn_union)] #![feature(const_generics)] #![feature(const_ptr_offset_from)]

Discussion:
Before we had branches in const fn we 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 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 attributes for the feature gate (or whatever other feature gates the compiler tells you to add) in case the const fn is already stable. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Hi, may I give this a go? claim
It's all yours! Let me know if you run into any troubles or need more info.
Hello! I'm having a bit of trouble cleaning up the functions in num. Specifically, I'm getting is not yet stable as a const fn`, which I'm not sure how to solve, on the changes in this commit here I started by reverting the body of to the pre-const-hack contents, and then adding the annotation to the function. However, the compiler complained with the following message: To me, it seemed because calls , and I had just made const unstable, I needed to mark as const unstable too. So, I did so, but this only changed the error message: At this point, I reverted marking as unstable, and checked the implementation of the check which was raising the error, and found it in . I saw this calls , so I checked its implementation in , and saw functions don't need to conform to minconstfn. Looking at the codebase, I saw there exists examples of other const unstable function which are able to call other functions without issue -- for example, (), and it appears that propagating the rustcconstunstable annotation to its callers is, indeed, the right thing to do. So, I tried marking 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 . Due to my annotation, the error message suggests that I add to the crate, but you can see .

For some time, I thought from the same file was missing an override of , that would look for , but realised because is an associated function, I wouldn't be able to pass the instance-specific 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/featuregate, before realising this is probably a case where I should ask for help. What's the (likely obvious :stuckouttongueclosedeyes: ) detail I'm missing here that's causing this issue?
rustcconststable may never be changed to rustcconstunstable, 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: (this attribute also takes a comma separated list of feature gates if you need multiple ones
I adjusted the main post, sorry about that misinformation
Ahh, you're all good :) Thanks!