Tracking issue for const slice::from_raw_parts_mut (const_slice_from_raw_parts_mut)

[DutchGhost]

Make slice::from_raw_parts and slice::from_raw_parts_mut a const fn available under a feature flag.
This would require a change in the ptr module as well, as slice module just forwards to it.

slice::from_raw_parts[mut] is used in alot of places (e.g slice::from_ref[mut], which would get one step closer into constification if slice::from_raw_parts[mut] is a const fn.

Here is a little playground to show it's possible:
https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=dd5c506a3e082c619f557d972e9956ff

In order to get this working, the following functions and functionalities need to be constified:

• ptr::slice_from_raw_parts (Make ptr::slice_from_raw_parts a const fn available under a feature flag #67462)

---

Implementation PR for ptr::slice_from_raw_parts: #67462

---

Partially stabilized in #97522; remaining unstable functions:

// core::ptr
pub const fn slice_from_raw_parts_mut<T>(data: *mut T, len: usize) -> *mut [T];

// core::slice
pub const unsafe fn from_raw_parts_mut<'a, T>(data: *mut T, len: usize) -> &'a mut [T];

// core::ptr::NonNull
pub const fn slice_from_raw_parts(data: NonNull<T>, len: usize) -> Self

[DoumanAsh]

Is there particular reason why it remains gated by feature flag instead of just being const fn as it is?

[DutchGhost]

Is there particular reason why it remains gated by feature flag instead of just being const fn as it is?

The constant versions of function's and methods in libcore/libstd need a period of time under a feature flag before they can be stabilized as a const function/method. Const functions are 'relatively' new, and the ability of what one can do inside isn't fully determined yet I think.
One of those abilities is how to handle raw pointers, which slice::from_raw_parts[mut] needs.

[josephlr]

@DutchGhost would it make sense for the slice::{from_raw_parts[_mut], from_ref, from_mut} to be constified behind this feature as well? The only thing that seems blocking that is this debug_assert which calls is_aligned_and_not_null.

Checking the alignment will need support from the MIR interpreter, see #62420

[DutchGhost]

@DutchGhost would it make sense for the slice::{from_raw_parts[_mut], from_ref, from_mut} to be constified behind this feature as well? The only thing that seems blocking that is this debug_assert which calls is_aligned_and_not_null.

Checking the alignment will need support from the MIR interpreter, see #62420

I'd say this indeed should fall under the same feature, as you wouldnt want to have 2 seperate features you need to track for really just one thing. Also I think once #79684 has landed, having a const slice::from_raw_parts is possible!!

[mbartlett21]

Cc. #57563

[DutchGhost]

This can now be implemented it seems. But Im not sure whether its decided yet what the plan is on allowing to cast pointers to usizes in const contexts, which is needed for is_aligned_and_not_null:

#![feature(const_ptr_is_null)]
#![feature(const_raw_ptr_to_usize_cast)]
#![feature(const_raw_ptr_deref)]
#![feature(const_slice_from_raw_parts)]
#![feature(const_panic)]


mod slice {
    use core::mem;
    use core::ptr;
    
    pub(crate) const unsafe fn is_aligned_and_not_null<T>(ptr: *const T) -> bool {
        !ptr.is_null() && ptr as usize % mem::align_of::<T>() == 0
    }

    pub const unsafe fn from_raw_parts<'a, T>(data: *const T, len: usize) -> &'a [T] {
        debug_assert!(
            is_aligned_and_not_null(data),
            "attempt to create unaligned or null slice"
        );
        debug_assert!(
            mem::size_of::<T>().saturating_mul(len) <= isize::MAX as usize,
            "attempt to create slice covering at least half the address space"
        );
        // SAFETY: the caller must uphold the safety contract for `from_raw_parts`.
        unsafe { &*ptr::slice_from_raw_parts(data, len) }
    }
    
    pub const fn from_ref<T>(reference: &T) -> &[T] {
        unsafe {
            from_raw_parts(reference, 1)
        }
    }
}

const X: &[usize] = slice::from_ref(&1);

fn main() {
    dbg!(X);
}

[mbartlett21]

@DutchGhost
You can type ptr as usize, but as soon as you try that in const-eval, you get a compiler error:

error: any use of this value will cause an error
  --> src/main.rs:13:27
   |
13 |         !ptr.is_null() && ptr as usize % mem::align_of::<T>() == 0
   |                           ^^^^^^^^^^^^
   |                           |
   |                           "pointer-to-integer cast" needs an rfc before being allowed inside constants
   |                           inside `is_aligned_and_not_null::<usize>` at src/main.rs:13:27
   |                           inside `slice::from_raw_parts::<usize>` at src/main.rs:18:13
   |                           inside `slice::from_ref::<usize>` at src/main.rs:31:13
   |                           inside `X` at src/main.rs:36:21
...
36 | const X: &[usize] = slice::from_ref(&1);
   | ----------------------------------------
   |
   = note: `#[deny(const_err)]` on by default

(playground)

[WaffleLapkin]

To clarify: this issue is currently tracking the following APIs being const:

// core::ptr
pub const fn slice_from_raw_parts<T>(data: *const T, len: usize) -> *const [T];
pub const fn slice_from_raw_parts_mut<T>(data: *mut T, len: usize) -> *mut [T];

// core::slice
pub const unsafe fn from_raw_parts<'a, T>(data: *const T, len: usize) -> &'a [T];
pub const unsafe fn from_raw_parts_mut<'a, T>(data: *mut T, len: usize) -> &'a mut [T];

The former two methods were implemented in #67462 and the latter two were implemented in #90377.

slice::from_{ref,mut} mentioned in the issue text as a const fn is tracked in #90206.

[tobz]

As an interested party: is there a path to eventual stabilization here, at least for some of the incremental work that is required? For example, std::ptr::slice_from_raw_parts has been available as a const fn (behind a feature flag) for over 2 years now... but I can't seem to find any actionable comments that provide a reason for it to not be stabilized.

Happy to try and learn/help to get it over the line. 🙏🏻

[WaffleLapkin]

I think that these API are ready for stabilization 🤔

APIs that return &mut/*mut are probably blocked on #57349, but the &/*const versions can be stabilized and only need https://github.com/orgs/rust-lang/teams/wg-const-eval FCP

[RalfJung]

@rust-lang/libs-api this should be ready. :) It const-stabilizes some long-stable functions, which is possible now that &mut is const-stable.

[dtolnay]

@rfcbot fcp merge

const for these stable functions:

• https://doc.rust-lang.org/nightly/core/ptr/fn.slice_from_raw_parts_mut.html
• https://doc.rust-lang.org/nightly/core/slice/fn.from_raw_parts_mut.html
• https://doc.rust-lang.org/nightly/core/ptr/struct.NonNull.html#method.slice_from_raw_parts

[rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.

[eduardosm]

@BurntSushi @joshtriplett @m-ou-se const_slice_split_at_mut (#101804), which depends on this, has entered FCP, so it would be nice to enter FCP here too.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[BurntSushi]

Weird. My box was ticked, but FCP didn't get triggered. I unticked and re-ticked my box.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.