Tracking Issue for using std::mem::transmute() in const fn (const_fn_transmute)

Using std::mem::transmute() in constant functions is behind the const_transmute/const_fn_transmute feature gate.
(In constants, it is stable.)

Blocked on rust-lang/const-eval#14.

Auto merge of #53535 - TheDarkula:master, r=oli-obk

I, for one, would love this, because I've had to use the union transmute hack more times than I feel comfortable. std::mem::transmute is still (super) unsafe, but at least it makes sure the types have the same size.

@mjbshaw

@mjbshaw It's already been merged :)

@TheDarkula

@TheDarkula I know. I'm just trying to show support for eventually stabilizing this feature (rather than being removed because people are opposed to it).

Even with the flag, is this possible? I am getting an error stating that the use of unsafe functions are not allowed in const fn:

pub const unsafe fn rx_buffer_init() -> [BufferDescriptor; BUFFER_CT] {
    transmute::<
        [u8; size_of::<BufferDescriptor>() * BUFFER_CT],
        [BufferDescriptor; BUFFER_CT]
    >([0u8; size_of::<BufferDescriptor>() * BUFFER_CT])
}

gives me

error: call to unsafe function is unsafe and unsafe operations are not allowed in const fn
  --> foo/src/test.rs:18:5
   |
18 | /     transmute::<
19 | |         [u8; size_of::<BufferDescriptor>() * BUFFER_CT],
20 | |         [BufferDescriptor; BUFFER_CT]
21 | |     >([0u8; size_of::<BufferDescriptor>() * BUFFER_CT])
   | |____________________________________________________________^ call to unsafe function
   |
   = note: consult the function's documentation for information on how to avoid undefined behavior

Is there some blocker on this or could this be starting to get stabilized? I'm mostly looking out for a way to define a function from a u8 array without any indirection but I have no idea whether this is supposed to be supported or not in the design of const fn.

unsafe in const fn has been stabilized in 1.33. Is there anything else left preventing this from being stabilized as well?

EDIT: Ugh, in fact, there is. For example, usize -> function pointer throws

error[E0080]: it is undefined behavior to use this value
...
type validation failed: encountered 10220800, but expected a pointer
|
= note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rust compiler repository if you believe it should not be considered undefined behavior

... which makes const_transmute pretty much useless for me.

Given that union field access is already possible inside const (but not inside const fn), it seems somewhat silly to block transmute. All that does is make code less readable by pushing people to use unions instead of transmutes.

So I propose we stabilize transmute in const, but not const fn. However, currently our handling of intrinsics in const-qualif is somewhat broken, so that should be fixed first.

Is there any summary of what the current status is here to actually get transmute to be const in const fn?

(Coming here because I'd have liked to make Path::new() const, but AFAIU this requires either pointer deref or transmute to be const, and transmute sounds easier to stabilize than pointer deref)

Raw pointers and transmute are pretty much equal in terms of "what it takes to make them const-stable".

The next step is to figure out what we want to do with UB during CTFE, for which I recently proposed an RFC: rust-lang/rfcs#3016. The key PR needed to implement that RFC is up at #78407.

I think it would be a good idea to split out into a separate feature that can be stabilized transmute of references to types that are repr(transparent) wrappers:

#[repr(transparent)]
pub struct MySlice(pub [u8]);

impl MySlice {
    pub const fn new(v: &[u8]) -> &MySlice {
        unsafe { std::mem::transmute(v) }
    }
}

I think once we find some kind of consensus on rust-lang/rfcs#3016 (which turned out to be much harder than I anticipated), there's not much blocking stabilization here.

@RalfJung

So, rust-lang/rfcs#3016 was merged. @RalfJung, does that mean we can proceed with stabilization here?

It seems to me that the answer is probably yes, since #75196 has a stabilization PR out and was previously blocked on rust-lang/const-eval#14.

Introduce macro to create static UncasedStrs

The stabilization PR is already up. :)
#85769

Navigation Menu

Repository navigation

Tracking Issue for using std::mem::transmute() in const fn (const_fn_transmute) #53605

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for using std::mem::transmute() in const fn (const_fn_transmute) #53605

Description

Activity

mjbshaw commented on Oct 2, 2018

TheDarkula commented on Oct 2, 2018

mjbshaw commented on Oct 2, 2018

jamesmunns commented on Oct 19, 2018

mgostIH commented on Mar 2, 2019

MSxDOS commented on Jun 22, 2019

RalfJung commented on Aug 29, 2019

11 remaining items

Ekleog commented on Dec 18, 2020

RalfJung commented on Dec 19, 2020

programmerjake commented on Apr 2, 2021

RalfJung commented on Apr 2, 2021

benesch commented on Jun 18, 2021

benesch commented on Jun 18, 2021

RalfJung commented on Jun 18, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions