#[allow_internal_unstable] does not allow unstable library features when applied on functions

[kennytm]

The #[allow_internal_unstable] attribute can only enable compiler features. Library features cannot be enabled.

Examples:

#![feature(allow_internal_unstable)]
// #![feature(wrapping_next_power_of_two, const_transmute)]

#[allow_internal_unstable(wrapping_next_power_of_two)]
fn g(a: u64) -> u64 {
    a.wrapping_next_power_of_two()
}

#[allow_internal_unstable(const_transmute)]
const fn h(a: u64) -> i64 {
    unsafe { std::mem::transmute(a) }
}

• Expected: can be built without errors.
• Actual: still complains about missing #![feature]s.

Rustc version = 1.43.0-nightly (2020-02-22 436494b8f8008b600d64)

[eddyb]

allow_internal_unstable is a macro attribute, the only bug here is that it doesn't complain when you put it on a non-macro.

[ecstatic-morse]

@eddyb This was changed as part of #63770.

[eddyb]

Ugh, that's an unprincipled hack, and the attribute is still not checked correctly. I had this example where it doesn't do anything without errors.

I can now see how it's used in libcore, but it should be named #[rustc_allow_const_fn_unstable(...)] or something, and be properly checked.

[eddyb]

Also, do we need that anymore? Given that we're starting to add more and more const fns.

[RalfJung]

Also, do we need that anymore? Given that we're starting to add more and more const fns.

The point of this is that we don't want to stabilize const fn that use unstable features (to avoid de-facto stabilizing unstable features of the const-eval engine). I think that is still very much needed.

[kennytm]

cc @Centril @oli-obk for use of #[allow_internal_unstable] around const fn. https://github.com/rust-lang/rustc-guide/blob/master/src/stability.md#allow_internal_unstable.

[ecstatic-morse]

The fix for this is described in #69373 (comment).