Tracking Issue for const_box

[lilasta]

Feature gate: #![feature(const_box)]

This is a tracking issue for implementing const Box<T, A> methods.

Public API

impl<T, A: Allocator> Box<T, A> {
    pub const unsafe fn from_raw_in(raw: *mut T, alloc: A) -> Self;
    pub const fn allocator(b: &Self) -> &A;
    pub const fn into_pin(boxed: Self) -> Pin<Self>
    where
        A: 'static;
}

Steps / History

• Implementation: Constify Box<T, A> methods #91884
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None

[beepster4096]

The non-ZST allocator issue has been resolved and should be removed from the unresolved questions list.

[lilasta]

Thanks for the information. I've removed it.

[rinarakaki]

I'm sorry for my shallow understanding, but can't Clone be constified for Box<T> at the same time?

[chorman0773]

Aparently it is possible on stable to Deref Box in a const-fn: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=52526e62eba8e2846bfcc45bdb04f47e

Was this intentional?

[lilasta]

I'm sorry for my shallow understanding, but can't Clone be constified for Box at the same time?

Currently it cannot. Rust's specialization doesn't yet support const-impl enough, so some Copy specializations will cause a compilation error. (Or we have to mark Copy as #[const_trait])
Example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=eab0289f5fc7537133a8df4ac6449323

rust/library/alloc/src/alloc.rs

Lines 424 to 443 in 8c0f83d

	pub(crate) trait WriteCloneIntoRaw: Sized {
	unsafe fn write_clone_into_raw(&self, target: *mut Self);
	}
	impl<T: Clone> WriteCloneIntoRaw for T {
	#[inline]
	default unsafe fn write_clone_into_raw(&self, target: *mut Self) {
	// Having allocated *first* may allow the optimizer to create
	// the cloned value in-place, skipping the local and move.
	unsafe { target.write(self.clone()) };
	}
	}
	impl<T: Copy> WriteCloneIntoRaw for T {
	#[inline]
	unsafe fn write_clone_into_raw(&self, target: *mut Self) {
	// We can always copy in-place, without ever involving a local value.
	unsafe { target.copy_from_nonoverlapping(self, 1) };
	}
	}

Aparently it is possible on stable to Deref Box in a const-fn
Was this intentional?

This behavior is not caused by this feature. It can be reproduced in pre-1.58.0. It may be due to the compiler's special DerefMove behavior.

[RalfJung]

This feature has been mostly removed by #110393, and anyway const_heap is still extremely experimental. Do the remaining methods make any sense to keep or should we just scratch this entirely for now?

[lilasta]

@RalfJung I believe there's little point in keeping the remaining methods. Would it be all right if I create a PR for the removal? As for #92523, I also plan to remove const and close it.

[RalfJung]

That makes sense for me -- @rust-lang/wg-const-eval what do you think?

[oxalica]

The non-ZST allocator issue has been resolved and should be removed from the unresolved questions list.

It seems Box::from_{raw,non_null} are not included here even with less challenges? They do not depend on const traits or custom allocators, and their functionalities is already implementable via a const transmute.
It's officially recommended to use NonNull::dangling() to construct a Box<ZST> if "Box::new cannot be used", while in fact Box::from_raw cannot be used in const context either and we need a less-semantic transmute currently.

playground

struct Zst;

const CONST_ZST: Box<Zst> = unsafe { std::mem::transmute(std::ptr::dangling::<Zst>()) };

fn main() {
    let free_box = CONST_ZST;
    dbg!(&raw const *free_box);
}

[RalfJung]

Constructing Box in const is generally unsupported, including for ZST. The fact that your code snippet works and does not cause UB is, I think, not a stable guarantee; you are relying on unstable implementation details.

[oxalica]

Constructing Box in const is generally unsupported, including for ZST. The fact that your code snippet works and does not cause UB is, I think, not a stable guarantee; you are relying on unstable implementation details.

So do you mean it has different requirement of validity (not sure if it's the correct word) for const and non-const context? I'm expecting const context can only be more strict and checked than runtime context, so if a code is guaranteed to be valid at runtime and it compiles at const context, it should be as valid/correct as runtime (excluding the result difference involving floating point calculations). Am I wrong on this?

It's currently explicitly mentioned Box<SizedT> has the same repr as a pointer to SizedT, and ptr::NonNull::dangling "is the recommended way to build it". I think it's a fair derivation to think std::mem::transmute::<*mut Zst, Box<Zst>>(std::ptr::dangling_mut()) is the correct and guaranteed to work. If it's not the case for const context, we probably need to update the docs to mention it.

For zero-sized values, the Box pointer has to be non-null and sufficiently aligned. The recommended way to build a Box to a ZST if Box::new cannot be used is to use ptr::NonNull::dangling.

On top of these basic layout requirements, a Box must point to a valid value of T.

So long as T: Sized, a Box is guaranteed to be represented as a single pointer and is also ABI-compatible with C pointers (i.e. the C type T*)

[RalfJung]

so if a code is guaranteed to be valid at runtime and it compiles at const context, it should be as valid/correct as runtime

That's definitely not correct; ptr-to-int transmutes (with their current de-facto but not-yet-stable semantics) are an example of that.

[oxalica]

so if a code is guaranteed to be valid at runtime and it compiles at const context, it should be as valid/correct as runtime

That's definitely not correct; ptr-to-int transmutes (with their current de-facto but not-yet-stable semantics) are an example of that.

ptr-to-int transmutes are rejected now in const-eval so it fails if part.

[RalfJung]

I don't know what you mean. They do not get rejected. Here's an example:

const C: () = {
    let x = &5;
    let y: usize = unsafe { std::mem::transmute(x) };
};

[oxalica]

I don't know what you mean. They do not get rejected. Here's an example:

const C: () = {
let x = &5;
let y: usize = unsafe { std::mem::transmute(x) };
};

🤦 Okay seems I have some misunderstanding about const-eval and it's not rejected until "used" in some sense.

Back to the original topic, you suggest that unsafe { std::mem::transmute::<*mut Zst, Box<Zst>>(std::ptr::dangling_mut()) } is guaranteed to create a valid Box::new(Zst) at runtime (though not so useful), but there is currently no stable and guaranteed way to initialize a const Z: Box<Zst>. Is this correct?

[RalfJung]

My first reaction was that this transmute is not specified to do anything in particular in any context, like all transmutes. If we do indeed guarantee this at runtime (which is a t-libs-api question that I am not so sure about) then arguably it should also work at compiletime.