Initializers of stable constants can call const unstable functions

[ecstatic-morse]

Crates using staged_api are forbidden from calling const unstable functions from stable const functions. However, this restriction does not extend to the initializers of consts or statics. Although unlikely, this could allow for "backdoor stabilization" of various const-eval features. For example, the following would lock in the current implementation of const_if_match.

#![stable(feature = "bar", since = "1.34")]

#![feature(staged_api)]
#![feature(const_if_match)]
#![feature(foo)]

#[rustc_const_unstable(feature = "foo", issue = "0")]
const fn foo() -> i32 {
    if true { 0 } else { 1 }
}

#[stable(feature = "bar", since = "1.34")]
pub const BAR: i32 = foo();

If BAR were a const fn instead of a const, that example would be rejected.

#[rustc_const_stable(feature = "bar", since = "1.34")]
pub const fn bar() -> i32 {
    foo()
}

cc @rust-lang/wg-const-eval

[ecstatic-morse]

I'm mostly wondering if this is intended, and if so, whether we could write down a set of rules to describe the expected behavior.

[ecstatic-morse]

It's not just calling unstable functions btw, there's no checks for rustc_allow_internal_unstable, so one could stabilize a const with &mut.

[Centril]

Archaeology time! We sorta decided to "risk it" and not inspect consts and statics in #53604 (comment) when we were first preparing to ship the stable const fn fragment. Note in particular (perhaps not true anymore?):

So... while I could actually implement a check that validates the MIR of constants in min_const_fn terms, this would be a major undertaking, requiring a new query and very hacky inspection of the MIR of constants at weird intervals.

I would be all for adding these checks if compiler changes have made those feasible to implement in a clean way.

[ecstatic-morse]

Makes sense. It's feasible now, and merging qualify_min_const_fn and check_consts would make my life easier, but it's kind of a pain to review since a lot of test output will change.