Function pointers break in const code after `~const` bounds are added

[cuviper]

Code

I first noticed this in #109122 (review), but there are also existing regressions from other ~const additions. For example:

type I32Cmp = fn(&i32, &i32) -> core::cmp::Ordering;
pub const fn min_by_i32() -> fn(i32, i32, I32Cmp) -> i32 {
    core::cmp::min_by
}

I expected to see this happen: compiles fine.

Instead, this happened: errors that ~const FnOnce is not implemented for the I32Cmp function pointer.

Details

error[E0277]: the trait bound `for<'a, 'b> for<'a, 'b> fn(&'a i32, &'b i32) -> std::cmp::Ordering: FnOnce<(&'a i32, &'b i32)>` is not satisfied
 --> error.rs:3:5
  |
3 |     core::cmp::min_by
  |     ^^^^^^^^^^^^^^^^^ expected an `FnOnce<(&i32, &i32)>` closure, found `for<'a, 'b> fn(&'a i32, &'b i32) -> std::cmp::Ordering`
  |
  = help: the trait `for<'a, 'b> ~const FnOnce<(&'a i32, &'b i32)>` is not implemented for `for<'a, 'b> fn(&'a i32, &'b i32) -> std::cmp::Ordering`
note: the trait `for<'a, 'b> FnOnce<(&'a i32, &'b i32)>` is implemented for `for<'a, 'b> fn(&'a i32, &'b i32) -> std::cmp::Ordering`, but that implementation is not `const`
 --> error.rs:3:5
  |
3 |     core::cmp::min_by
  |     ^^^^^^^^^^^^^^^^^
note: required by a bound in `std::cmp::min_by`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.

Version it worked on

For that particular example, it most recently worked on: 1.65.0

Version with regression

After #102245 reached stable, rustc --version --verbose:

rustc 1.66.0 (69f9c33d7 2022-12-12)
binary: rustc
commit-hash: 69f9c33d71c871fc16ac445211281c6e7a340943
commit-date: 2022-12-12
host: x86_64-unknown-linux-gnu
release: 1.66.0
LLVM version: 15.0.2

... but I don't mean to pick on that particular PR -- I think there's a more general problem with ~const here.

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[Mark-Simulacrum]

Nominating for libs-api - though may want to hold discussion until there's a const folks opinion on how hard a fix will be in the compiler. The code is pretty esoteric but still seems bad to break.

@cuviper did this appear in real world code? Or just happened to stumble across it?

[cuviper]

It appeared as a new error in tests/ui/consts/issue-102117.rs, where it suddenly wanted const-droppable T for the new ~const bounds on drop_in_place in #109122. That case actually seems fairly realistic for manual vtables, but I haven't seen any other errors like this in the wild.

[thomcc]

CC @rust-lang/wg-const-eval

[fee1-dead]

I'm going to take a look on resolving this in the compiler.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high