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

[RalfJung]

All right, with #84556 the last effect of const_fn is gone. :)
Once that lands, we can start removing const_fn from crates (in particular, lock_api) and tests, and then eventually mark the feature gate as "removed".

[RalfJung]

With #84556 having landed, the const_fn feature gate is now dead code. We can start removing it everywhere, and then eventually mark the feature gate itself as removed in the compiler (so it is rejected during the build).