Stabilize const_fn_fn_ptr_basics, const_fn_trait_bound, and const_impl_trait

[eholk]

Stabilization Report

This PR serves as a request for stabilization for three const evaluation features:

1. const_fn_fn_ptr_basics
2. const_fn_trait_bound
3. const_impl_trait

These are being stabilized together because they are relatively minor and related updates to existing functionality.

const_fn_fn_ptr_basics

Allows creating, passing, and casting function pointers in a const fn.

The following is an example of what is now allowed:

const fn get_function() -> fn() {
    fn foo() {
        println!("Hello, World!");
    }
    
    foo
}

Casts between function pointer types are allowed, as well as transmuting from integers:

const fn get_function() -> fn() {
    unsafe {
        std::mem::transmute(0x1234usize)
    }
}

However, casting from a function pointer to an integer is not allowed:

const fn fn_to_usize(f: fn()) -> usize {
    f as usize  //~ pointers cannot be cast to integers during const eval
}

Calling function pointers is also not allowed.

const fn call_fn_ptr(f: fn()) {
    f() //~ function pointers are not allowed in const fn 
}

Test Coverage

The following tests include code that exercises this feature:

• src/test/ui/consts/issue-37550.rs
• src/test/ui/consts/issue-46553.rs
• src/test/ui/consts/issue-56164.rs
• src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs
• src/test/ui/consts/min_const_fn/cast_fn.rs
• src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs

const_fn_trait_bound

Allows trait bounds in const fn. Additionally, this feature allows creating and passing dyn Trait objects.

Examples such as the following are allowed by this feature:

const fn do_thing<T: Foo>(_x: &T) {
    // ...
}

Previously only Sized was allowed as a trait bound.

There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants.

This feature also allowes dyn Trait types. These work equivalently to non-const code. Similar to other pointers in const code, the value of a dyn Trait pointer cannot be observed.

Note that due to #90912, it was already possible to do the example above as follows:

const fn do_thing<T>(_x: &T) where (T,): Foo {
    // ...
}

Test Coverage

The following tests include code that exercises const_fn_trait_bound:

• src/test/ui/consts/const-fn.rs
• src/test/ui/consts/issue-88071.rs
• src/test/ui/consts/min_const_fn/min_const_fn.rs
• src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs
• src/test/ui/nll/issue-55825-const-fn.rs
• Many of the tests in src/test/ui/rfc-2632-const-trait-impl/ also exercise this feature.

const_impl_trait

Allows argument and return position impl Trait in a const fn, such as in the following example:

const fn do_thing(x: impl Foo) -> impl Foo {
    x
}

Similar to generic parameters and function pointers, this allows the creation of such opaque types, but not doing anything with them beyond accessing associated types and constants.

Test Coverage

The following tests exercise this feature:

• src/test/ui/type-alias-impl-trait/issue-53096.rs
• src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs

Documentation

These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html.

There is a PR that updates this documentation to reflect the capabilities enabled by these features at rust-lang/reference#1166.

Tracking issues: #57563, #63997, #93706

[rust-highfive]

Some changes occurred in src/tools/clippy.

cc @rust-lang/clippy

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[fee1-dead]

Oh, you beat me to it! Nice work!

[eholk]

I have a documentation PR at rust-lang/reference#1166.

[fee1-dead]

Please also remove ops::ty::DynTrait as well as ops::ty::TraitBoundNotConst. dyn should be part of the stabilization and the latter was obsolete after I introduced ~const.

[RalfJung]

Cc @rust-lang/wg-const-eval

[RalfJung]

To be clear, what is being "stabilized" here is simply mentioning the types fn() and dyn Trait in const fn -- there is no way to actually do anything with these types during CTFE, other than pass them around and use them to initialize a static/const.

Actually having function pointers or trait objects that can be called during CTFE is future work, and will require new syntax.

[eholk]

Please also remove ops::ty::DynTrait as well as ops::ty::TraitBoundNotConst. dyn should be part of the stabilization and the latter was obsolete after I introduced ~const.

Done! DynTrait was already gone, but I just got rid of TraitBoundNotConst too.

[oli-obk]

I think my comment on zulip got drowned out by the other thread XD. Repeating it here:

Awesome! Looked over it and it lgtm. If you want you can also throw const_impl_trait out in the same PR.

Wrt documentation, all that needs updating is the reference in https://doc.rust-lang.org/stable/reference/const_eval.html?highlight=Const#const-functions

[oli-obk]

To be clear, what is being "stabilized" here is simply mentioning the types fn() and dyn Trait in const fn -- there is no way to actually do anything with these types during CTFE, other than pass them around and use them to initialize a static/const.

Actually having function pointers or trait objects that can be called during CTFE is future work, and will require new syntax.

Repeating this comment, as I'm now nominating this PR for @rust-lang/lang to consider. In the const eval meeting we had right before the new year and in the zulip discussion afterwards, there seemed resounding support for this PR's change.

The changes from this PR already had existing workarounds, so no new behaviour is stabilized, just convenient syntax:

• Stabilization error E0658 is trivially bypassed #90912
• Tracking issue for const fn pointers #63997 (comment)

[bors]

☔ The latest upstream changes (presumably #93893) made this pull request unmergeable. Please resolve the merge conflicts.

[Mark-Simulacrum]

The PR title suggests this is aiming to stabilize both const_fn_trait_bound and const_fn_fn_ptr_basics, the latter of which seems to be what your comment discusses, whereas const_fn_trait_bound is not addressed? Are these features coupled in some way, or is it just being stabilized in the same PR for convenience?

Regardless, I think it would be good to write a more complete description of the changes here into the PR description -- just because this is stabilizing 'nicer syntax' rather than truly new functionality IMO does not mean that we should side step a stabilization report for this new feature, even if it is relatively simple -- some questions that I have:

• What are our semantics for creating fn-ptr or dyn Trait values in const fn? Is behavior here equivalent to behavior in regular functions?
• Can the value of the fn-ptr or dyn Trait be observed? (e.g., by transmuting)
• Can you cast from usize or similar to an fn-ptr (or in theory dyn Trait) in const fn?

IOW, it seems like it would be a reasonable step to stabilize these as-if we were in a world where they were entirely inaccessible in const fn, since that is the blessed world from a language perspective.

For const fn trait bounds, I think a similar approach of 'from scratch' stabilization, rather than a delta with the already stable language would be good. Obviously, some (all?) of the decisions have already been fairly fixed in place, but having that stabilization report would let us discuss whether some of them are in hindsight a bad idea, and potentially propose either edition changes or otherwise break the behavior in the future; skipping the stabilization report doesn't really do us much good.

---

More on a T-compiler perspective -- it sounds like the stabilization here (via the workarounds) was done largely by accident -- have we expanded test coverage or considered what can be done to avoid future mistakes? Is there some extra validation we should try to do?

[eholk]

Thanks for the comments and questions, @Mark-Simulacrum. This is my first time going starting the stabilization process, and somehow I missed the big section on "Write a stabilization report" when I read https://rustc-dev-guide.rust-lang.org/stabilization_guide.html. I agree that these features do not warrant side-stepping the normal process. I'll take some time to write up a proper report and make sure to address the questions you raised as well as the other points mentioned in the dev guide.

[eholk]

Awesome! Looked over it and it lgtm. If you want you can also throw const_impl_trait out in the same PR.

Ah, sorry I missed this part. I just pushed another commit that includes const_impl_trait.

[bors]

☔ The latest upstream changes (presumably #93956) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

I'll second what @Mark-Simulacrum wrote, a stabilization report would be great. I will also say that in some recent conversations, @tmandry and I were landing on designs that really wanted the ability to write a const fn that returns a function pointer, with the assumption that the resulting fn pointer would be something the compiler can statically link to (or at least know that it cannot). So I'm excited to see this being proposed for stabilization and, separately, I'd like to talk over with @oli-obk and make sure that the plans @tmandry and I are dreaming up align with overall reality.

[jplatte]

I'm doubtful about the const_fn_trait_bound stabilization going in the right direction, #93706 is probably the right place to discuss.