Remove `qualify_min_const_fn` and `#![feature(const_fn)]`

[ecstatic-morse]

We currently have two separate MIR passes that are responsible for const-checking. One lives in the check_consts directory, and is responsible for the checks that run in all const contexts. The other is qualify_min_const_fn, which performs additional checks within const fn when #![feature(const_fn)] is not enabled. The split was necessary to push const fn feature over the finish line due to technical debt in the const-qualification code, but it resulted in some checks being duplicated between the two modules. Const-qualification has since been rewritten entirely, and it should be possible to unify the two to reduce the maintenance burden and improve diagnostics.

I half-heartedly attempted this in #68940, but eventually abandoned it due to the volume of error message changes and reticence from a former lang-team member. However, I think we should give this another try, since the split has caused some confusion about #![feature(const_fn)] (see #76602) and there was a request from the libs-team to change how stability attributes affect whether the qualify_min_const_fn runs (see #75794).

I did not fully understand when writing #68940 that qualify_min_const_fn is responsible for ensuring that publicly exported, stable const fn in staged_api crates do not rely on unstable features as part of their implementation. check_consts makes no such effort. So far, we've relied on the review process to enforce this, but I think one of the first steps will be to add this functionality to check_consts, enabling it only within const fn at first. After that, we can define new structured errors for each of the checks in qualify_min_const_fn in the check_consts framework and disable the former entirely. At first, all of these checks will be controlled by the #![feature(const_fn)] feature gate, but I think we should assign a new gate to each (floating point arithmetic within const fn, impl Trait, etc.).

@oli-obk, would you be willing to review this work? Is there anything I missed?

TODO:

• Fully remove qualify_min_const_fn
• ... (list needs completing)

cc @rust-lang/wg-const-eval

[RalfJung]

So far, we've relied on the review process to enforce this

I am confused, haven't we relied on qualify_min_const_fn to enforce this?

[ecstatic-morse]

For checks that exist in both qualify_min_const_fn and check_consts, yes. However, not everything in check_consts has an analogue in qualify_min_const_fn. const_precise_live_drops for sure does not, and I believe there are others (MutDeref?).

[RalfJung]

Ah, so basically when check_consts was extended to accept more things, we sometimes forgot to extend qualify_min_const_fn to make sure it rejects them? That is surprising as I thought qualify_min_const_fn was a tight whitelist and thus wouldn't accept any of these new features.

[josephlr]

I believe there are others (MutDeref?).

So it looks like stable library functions can't use MutDeref, as qualify_min_const_fn has a specific type-level check that bans any mutable references. However, this only applies in functions not constants, leading to a strange outcome where:

const FOO: Option<&mut i32> = None;

is allowed on stable, but

const fn bar() {
    let x: Option<&mut i32> = None;
}

is not, playground link.

The corresponding check in check_consts bans the operation of taking mutable references, rather than the type itself. These checks not being exactly the same mostly just seem to cause weird compiler errors (with incorrect recommendations).

That is surprising as I thought qualify_min_const_fn was a tight whitelist and thus wouldn't accept any of these new features.

This seems mostly true, an example of where it's not is the type-level check, which checks for some banned types, and then lets all other types pass through, which means if a new const-incompatible type/operation was added, this check would need to be updated.

[RalfJung]

leading to a strange outcome

Note that we have a few cases where things are allowed in constants but not const fn. Union field access and mem:.transmute are further examples.

[oli-obk]

would you be willing to review this work?

yes definively!