Make core::mem::zeroed() a const fn

[alex]

Right now this isn't callable from const fns. This would be useful for using const fns in combination with FFI.

[alex]

(Apologies if this shouldn't have a dedicated issue, it didn't seem to be covered by any of the existing A-const-fn bugs)

[alex]

I copied mem::zeroed into my project and marked it as as const fn:

error: any use of this value will cause an error
   --> /home/alexgaynor/projects/linux-kernel-module-rust/src/chrdev.rs:125:5
    |
125 |       intrinsics::panic_if_uninhabited::<T>();
    |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |       |
    |       "calling intrinsic `panic_if_uninhabited`" needs an rfc before being allowed inside constants
    |       inside call to `linux_kernel_module::chrdev::zeroed::<linux_kernel_module::bindings::file_operations>` at /home/alexgaynor/projects/linux-kernel-module-rust/src/chrdev.rs:132:71
    |       inside call to `linux_kernel_module::chrdev::FileOperationsVtable::new::<CycleFile>` at src/lib.rs:14:9
    | 
   ::: src/lib.rs:13:5
    |
13  | /     const VTABLE: linux_kernel_module::chrdev::FileOperationsVtable =
14  | |         linux_kernel_module::chrdev::FileOperationsVtable::new::<Self>();
    | |_________________________________________________________________________-
    |
    = note: #[deny(const_err)] on by default

So there's more work here than simply marking it const. I don't fully understand this error message -- it seems to happen for calls to any intrinsic, so I guess there's a deeper question there.

[alex]

Ah, source diving it seems that message simply means that support for the intrisinc hasn't been added to the MIR interpreter: https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/intrinsics.rs#L44

Does adding support for these need their own bugs, or can they just be covered here?

[alex]

After source diving a bit, I'd be happy to provide a PR to implement panic_if_uninhabited, if it's wanted. I'd be happy to do init as well, but I'd need a bit more guidance, I don't quite understand how that'd work just from looking at the other intrinsic implementations.

[RalfJung]

Cc @oli-obk

mem::zeroed and mem::uninitialized are a mess (the latter is deprecated), so I am opposed to making either of them const fn.

What should become a const fn is MaybeUninit::zeroed. But that is still waiting on some more CTFE work, I think.

[RalfJung]

Ah, source diving it seems that message simply means that support for the intrisinc hasn't been added to the MIR interpreter

All of these intrinsics are already implemented in Miri at https://github.com/rust-lang/miri/blob/master/src/intrinsic.rs. But so far they deliberately were not moved into rustc proper.

[oli-obk]

What should become a const fn is MaybeUninit::zeroed. But that is still waiting on some more CTFE work, I think.

We could make just the zeroed intrinsic const fn then MaybeUninit::zeroed can be const fn immediately and we can un-const-fn the zeroed intrinsic (or even remove it entirely, once we get loops and conditions in const fn)

Or we can try getting

union Foo<T> {
    a: [u8; std::mem::size_of::<T>()],
    b: T,
}

to work, but that's lazy normalization, so... 😆

[oli-obk]

mem::zeroed and mem::uninitialized are a mess (the latter is deprecated), so I am opposed to making either of them const fn.

I'm in full agreement, the mem::zeroed and mem::uninitialized functions should never become const fn.

[RalfJung]

My concern is with the implementation of the zeroed intrinsic (actually called init).

What's missing to make MaybeUninit::zeroed a const fn? Probably support for mutable references?

[RalfJung]

But given that people have been asking for this for quite a while... do you think it is realistic to add an implementation of the init intrinsic now, but remove it again later once we got everything together to have the current implementation of zeroed in CTFE?

[RalfJung]

Oh, you basically suggested that above.^^ Sorry.

So I think I wouldn't block that plan:

1. Move the init and uninit implementations from Miri to librustc_mir. (Having the two not in the same place seems odd.)
2. Make init unstable available as a const fn, use that to implement MaybeUninit::zeroed.
3. Open an issue that says we will want to completely kill both of these intrinsics as soon as CTFE gets powerful enough to make MaybeUninit::zeroed a const fn without them.

If we want to avoid seeing uninit in librustc_mir, maybe we can kill that intrinsic today (and implement mem::uninitialized as MaybeUninit::uninit().assert_init()). That would be a separate 0th step then.