Treat const fn like fn for promotion.

[RalfJung]

rust-lang/const-eval#19 gives many arguments for why we should not promote const fn calls. However, we currently do promote const fn calls in const fn, even though that has all the same problems. This fails to compile, but really we shouldn't make this a hard error:

#![allow(unconditional_panic, const_err)]

const fn foo() { [()][42] }
pub const fn do_something(b: bool) -> i32 {
    if b {
        let _x = &foo();
    }
    13
}

This does not just apply to const fn calls; all promotion inside const fn should be treated like inside fn.

Cc @rust-lang/wg-const-eval

[RalfJung]

#75502 is a crater experiment to stop doing this (at least for the case of &call() inside const fn).

[oli-obk]

One data point I want to bring up is rust-lang/rfcs#1229 (comment)

It's probably worth adding to the RFC a definition of "constant evaluation" vs "runtime evaluation" contexts. I think that the language has a pretty clear distinction, though:

• the initializer of a constant const foo: ty = EXPR or static foo: ty = EXPR
• the size of an array [T; EXPR]

The body of a const fn is sort of interesting. I think my preference is that the body is treated as a constant evaluation context, and hence an error is reported, even if the const fn is never called from a constant initializer -- so long as the overflow can be observed without knowing the values for these arguments. Implementing this, of course, will require a more sophisticated handling of constants (which we need anyhow). Since const fn is feature-gated we have time to play with this. Similar concerns will apply to generic and associated constants of course. I think from the POV of this RFC we can leave this as an "unresolved question", or at least as an open bug that will not be impl'd immediately.

From that reading I'm getting the vibes that @nikomatsakis would be mostly fine with hard erroring on promotion or even const propagation of failing code in const fn. But since we did not address this during the stabilization of const fn... this train probably left?

[RalfJung]

The reason promotion in fn is subtle is that it needs to be codegen'd, and we cannot say if the code we are generating will ever evaluate or not. There might be things like

fn foo<T: Trait>() -> &'static i32 {
  if T::ASSOC != 0 { &(14/T::ASSOC) } else { panic!() }
}

which would never cause div-by-zero at runtime, but will have a failing CTFE query during codegen if T::ASSOC is 0.

And all of this applies equally to const fn! They are still fn, subject to codegen, and thus have all the same problems. I don't see how them being a "const context" is at all related. Even in a "const context" I would not expect code that properly guards against div-by-zero to cause a compile-time error.