Tracking issue for unsafe operations in const fn

[Centril]

This is a tracking issue for the RFC "Const functions and inherent methods" (rust-lang/rfcs#911).

This issue only tracks a subset of the proposal in 911 that we are (hopefully) comfortable with stabilizing. To opt into the minimal subset, use #![feature(min_const_unsafe_fn)]. To use the more expansive feature set, you can continue using #![feature(const_fn)] and other associated feature gates.

Currently, while you can write unsafe {} inside a const fn / unsafe const fn, it is not possible to actually possible to call any unsafe operations inside the block. This makes it impossible to implement safe const fn abstractions such as Vec::new. This issue builds upon #53555 by allowing you to use unsafe operations inside const fn so that we can make more abstractions const fn.

Exhaustive list of features supported in const fn with #![feature(min_const_unsafe_fn)]:

0. Constructing types (e.g. NonZero) with #[rustc_layout_scalar_valid_range_start] becomes unsafe. This is an internal bug-fix that has no user facing consequences. A motivation is given in Tracking issue for unsafe operations in const fn #55607 (comment) and in Tracking issue for unsafe operations in const fn #55607 (comment).
1. Calling const unsafe fn functions inside const fn functions inside an unsafe { ... } block.
2. Calling const unsafe fn functions inside const unsafe fn functions.

Non-exhaustive lists of things that don't become allowed with #![feature(min_const_unsafe_fn)]:

3. Calling const unsafe fn functions directly inside other const unsafe fn functions.
   For example:

   const unsafe fn foo() {}
   const unsafe fn foo() {
       bar(); // <-- ERROR! You must write `unsafe { bar(); }`.
   }

   We impose this restriction because @RalfJung has noted that this is not a good thing in unsafe fn and fn. Thus, for now, we want to avoid making the situation worse in const unsafe fn. We can lift the restriction later if we want to.

   EDIT: This restriction has been removed.

4. Calling ptr::read, mem::transmute or other functions that can't be written as const unsafe fn in user code (see discussion below...).

5. Defererencing raw pointers; Tracked in [tracking issue] dereferencing raw pointers inside constants (const_raw_ptr_deref) #51911.

6. Union field accesses; Tracked in [tracking issue] union field access inside const fn #51909.

7. Casting raw pointers to integers

8. Taking references to fields of packed structs

9. accessing extern statics

Things to be done before stabilizing:

• Implement the min_const_unsafe_fn feature gate. (Allow calling const unsafe fn in const fn behind a feature gate #55635)
• Ensure that the above restrictions apply.
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

None.

Vocabulary:

• CTFE
• promoted
• rvalue promotion

---

cc #24111.

[Centril]

Also cc @rust-lang/lang @RalfJung

[oli-obk]

Details can be found via rust-lang/const-eval#14

the TLDR is that if we allow e.g. transmute as a const fn and be called within const fn by using unsafe, we might be producing values that are fine at runtime but not at compile-time.

A prominent example is transmute::<&T, usize>(&whatev) / 2. Dividing an address by two is useless but legal at runtime. At compile-time this value cannot be known (because we don't know at which address llvm and the OS will place any objects) and we thus bail out.

[RalfJung]

To elaborate on what @oli-obk said, imagine someone wrote

const fn totally_safe_fn(x: &i32) {
  unsafe { transmute::<&i32, usize>(x) / 2 }
}

How do we communicate and teach that this is NOT okay? As usual there is a proof obligation that the unsafety is properly encapsulated within this safe function; it's just that adding const changes the proof obligation. Without const the example above would be safe to call; with const it is not. IOW, the function is "unconst".

[Centril]

Me and @oli-obk briefly discussed the matter further on Discord.
Here is the conversation in full (edited for clarity):

@Centril wrote:

---

So having read yours and Ralf's replies and also const-eval/const_safety.md, I have thoughts:

0. Is there an exhaustive list of the unconst-behavior-triggering operations anywhere (these will be needed for the stabilization report of allowing unsafe { .. }
1. mem::transmute(_copy) -- can we simply get away with not making this unsafe const fn for the time being and see how much we can constify without it?
2. Would there be any ways beside the currently gated ops and transmute to do unconst behavior on stable?
3. We have:

   pub unsafe fn transmute_copy<T, U>(src: &T) -> U {
       ptr::read(src as *const T as *const U)
   }

so we then need to ensure that ptr::read is also not stably const fn or that src as *const T as *const U isn't (it is already, https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=c7957a6eecccae81ebb6d0289f91484a)

@oli-obk wrote:

---

Yeah, everything that can be problematic is behind extra feature gates.
I'll come up with the exhaustive list.
You can't take back casting things to raw pointers, because you can do that in constants,
so ptr::read needs to stay unstable, yes.
The list is very short: any unsafe operation, ptr to int casts, ptr operators (e.g. equality).
Without UCG it feels like it makes little sense to state which unsafe ops are fine.
What we can say is that just allowing calling unsafe min_const_fn is fine, because their bodies are
restricted to the same rules.

With this said, I think we can / should do the following:

1. Stabilize the calling of const unsafe fn inside const fn in an unsafe { ... } block.
2. Stabilize the calling of const unsafe fn inside const unsafe fn in an unsafe { ... } block.
   • This is an intentional restriction; we don't permit:

     const unsafe fn foo() {}
     const unsafe fn foo() { bar(); }

     We impose this restriction because @RalfJung has noted that this is not a good thing in unsafe fn and fn.
     We can lift the restriction later if we want to.
3. Keep the unconst things unconst.
4. In particular wrt. 3, we don't allow ptr::read and mem::transmute(_copy) to be callable inside unsafe { ... } inside const unsafe fn / const fn + unsafe { ... }.
5. We see how much of important standard library / ecosystem pieces such as Vec::new we can constify -- and evaluate what needs to be done wrt. 3. and 4. after that.

[oli-obk]

I think you swapped const fn and const unsafe fn in 1.

[Centril]

@oli-obk Oops, fixed. =P

[Centril]

@rfcbot merge

I propose that we extend the stable const unsafe? fn fragment of the language marginally, as provided for by rust-lang/rfcs#911 and in particular rust-lang/rfcs#1245, with (as noted in the issue description):

0. Constructing types (e.g. NonZero) with #[rustc_layout_scalar_valid_range_start] becomes unsafe. This is an internal bug-fix that has no user facing consequences. A motivation is given in Tracking issue for unsafe operations in const fn #55607 (comment) and in Tracking issue for unsafe operations in const fn #55607 (comment).
1. Calling const unsafe fn functions inside const fn functions inside an unsafe { ... } block.
2. Calling const unsafe fn functions inside const unsafe fn functions.

The points 1-2 are very conservative (in particular, 3. makes it even more conservative...) and provides a natural evolution of the piecemeal stabilization of const fn that we started with in #53555.

Among other things we will not allow (as noted in the issue description):

3. Calling const unsafe fn functions directly inside other const unsafe fn functions.
   For example:

   const unsafe fn foo() {}
   const unsafe fn foo() {
       bar(); // <-- ERROR! You must write `unsafe { bar(); }`.
   }

   We impose this restriction because @RalfJung has noted that this is not a good thing in unsafe fn and fn. Thus, for now, we want to avoid making the situation worse in const unsafe fn. We can lift the restriction later if we want to.

   EDIT: This restriction has been removed.

4. Calling ptr::read, mem::transmute or other functions that can't be written as const unsafe fn in user code (see discussion above...).

5. Defererencing raw pointers; Tracked in [tracking issue] dereferencing raw pointers inside constants (const_raw_ptr_deref) #51911.

6. Union field accesses; Tracked in [tracking issue] union field access inside const fn #51909.

7. Casting raw pointers to integers

8. Taking references to fields of packed structs

9. accessing extern statics

---

The implementation and tests for it is pending in #55635.
While that is not yet merged, let's wait for that to happen, and so therefore:

@rfcbot concern implementation
@rfcbot concern tests

[rfcbot]

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Centril
• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

Concerns:

• implementation resolved by Tracking issue for unsafe operations in const fn #55607 (comment)
• tests resolved by Tracking issue for unsafe operations in const fn #55607 (comment)
• unsafe-in-unsafe resolved by Tracking issue for unsafe operations in const fn #55607 (comment)

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.