Get rid of "const_fn" feature gate

[RalfJung]

With #84310, the const-checking analysis in compiler/rustc_mir/src/transform/check_consts no longer cares about the const_fn feature gate. So it's time we remove it entirely. That, however, turns out to be non-trivial -- I tried.

• Some external creates need to be patched first to not use const_fn any more:

error[E0557]: feature has been removed
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/lock_api-0.4.1/src/lib.rs:91:42
   |
91 | #![cfg_attr(feature = "nightly", feature(const_fn))]
   |                                          ^^^^^^^^ feature has been removed
   |
   = note: replaced by finer-grained feature flags

• Something very strange is going on with the "const fn in trait" errors. In my attempt I made this a new feature gate, which however just lead to tons of duplicate errors.
• Something else but equally strange is going on with some cases of having trait bounds on const fn, leading to errors disappearing in the min_const_fn test.

Cc @rust-lang/wg-const-eval

[RalfJung]

Regarding "const fn in trait", I think what happens is that currently, parsing this is gated on const_fn but then still gets rejected later. So maybe the easiest way forward here would be to just reject this in the parser always, even under const_fn -- what do you think @oli-obk?

[oli-obk]

How can we reject it in the parser? We need to know about bounds and similar which we usually check on the HIR I think?

[RalfJung]

I mean this:

trait Foo {
  const fn bar();
}

I think this is not currently allowed under any conditions, is it? We accept it in the parser if const_fn is set, only to later reject it somewhere.

[oli-obk]

I mean this:

trait Foo {
  const fn bar();
}

I think this is not currently allowed under any conditions, is it? We accept it in the parser if const_fn is set, only to later reject it somewhere.

oh... yea, just forbid that without any way to enable it

[RalfJung]

Turns out we already forbid it:

rust/compiler/rustc_ast_passes/src/ast_validation.rs

Line 1411 in b78c0d8

self.check_trait_fn_not_const(sig.header.constness);

So, I think we can just remove the feature gate check.

[RalfJung]

All right, opened #84544 for that.

What is still confusing me a lot is this one:

rust/compiler/rustc_mir/src/const_eval/fn_queries.rs

Line 81 in a8ff647

!tcx.features().const_fn

This is inside is_min_const_fn. What does that even mean? In the past I think we had two const-checkers, and is_min_const_fn decided whether the "minimal" or the "full" checker was used. Nowadays, we only have one checker, right? So should is_min_const_fn even still exist?
There is exactly one call site:

rust/compiler/rustc_mir/src/transform/check_unsafety.rs

Line 500 in fb4f48e

(tcx.is_const_fn_raw(def.did.to_def_id()), is_min_const_fn(tcx, def.did.to_def_id()))

The result is then passed to the unsafety checker where it has exactly one consequence:

rust/compiler/rustc_mir/src/transform/check_unsafety.rs

Line 338 in fb4f48e

if self.min_const_fn {

I don't think whether something is "min" or "not-min" const fn should affect unsafety checking. Do you think we can remove this code (and just treat all functions like min_const_fn as far as unsafety checking is concerned)?

[oli-obk]

yea, all mentions of "min_const_fn" should disappear and instead just be checks for whether the function is_const_fn_raw

[RalfJung]

All right, #84547 is underway doing that.

This means there is just one reference to the const_fn feature gate left:

rust/compiler/rustc_mir/src/transform/check_consts/validation.rs

Line 445 in 46d09f7

} else if !tcx.features().const_fn

This is probably what caused the strange side-effects last time...
since this is about trait bounds, maybe the most sensible thing to do is to use the const_fn_trait_bound feature gate instead of the const_fn feature gate?

[oli-obk]

Yea, that sounds like the best thing to do here

[oli-obk]

Though I'm moderately confused about the inversion of the check

[oli-obk]

I would have thought that means we can just scrap the check entirely instead of using a different feature gate