Skip to content

unstable const fns in libcore can be ignored by const-qualification  #67053

Closed

Description

As shown in #66884 (comment) const-qualification can ignore some const fns, in the context of libcore / rustc crates:

#![stable(feature = "core", since = "1.6.0")]
#![feature(const_if_match)]
#![feature(rustc_const_unstable)]
#![feature(staged_api)]

enum Opt<T> {
    Some(T),
    None,
}

impl<T> Opt<T> {
    #[rustc_const_unstable(feature = "foo")]
    #[stable(feature = "rust1", since = "1.0.0")]
    const fn unwrap_or_else<F: FnOnce() -> T>(self, f: F) -> T {
        match self {
            Opt::Some(t) => t,
            Opt::None => f(),
        }
    }
}

playground

This should not compile without "miri unleashed"; const-qualification does not see this function as const since the unstable feature is not enabled, and thus does not check it.

It does not compile outside of libcore, nor if the unstable feature is enabled in libcore.

cc @ecstatic-morse @oli-obk

More discussion is also available in this zulip thread.

I have a fix and will post a PR shortly. There are a couple of existing cases in libcore where this matters (for const_ptr_offset_from and const_type_name), and I'll fix those at the same time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

A-const-evalArea: Constant evaluation (MIR interpretation)A-const-fnArea: const fn foo(..) {..}. Pure functions which can be applied at compile time.A-stabilityArea: `#[stable]`, `#[unstable]` etc.C-bugCategory: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions