Returning `MaybeUninit` `const`s generates code to zero out the return value.

[rodrimati1992]

I tried this code:

use std::mem::MaybeUninit;

pub const fn foo() -> MaybeUninit<[u8; 10]> {
    const M: MaybeUninit<[u8; 10]> = MaybeUninit::uninit();
    M
}

pub const fn bar() -> MaybeUninit<[u8; 10]> {
    MaybeUninit::uninit()
}

I expected to see this happen: Both functions to compile to just a return instruction

Instead, this happened: Only bar did, foo zeros the return value in release builds.

playground::foo: # @playground::foo
# %bb.0:
	xorl	%eax, %eax
	xorl	%edx, %edx
	retq
                                        # -- End function

playground::bar: # @playground::bar
# %bb.0:
	retq
                                        # -- End function

Meta

rustc --version --verbose:

1.53.0-nightly (2021-03-28 4a20eb6a9da36c88ee92)

[rodrimati1992]

This turns into a memset when the array is large, which is significantly slower than doing nothing

[RalfJung]

Cc @oli-obk

[RalfJung]

Good catch! Yes we probably could be emitting proper undef constants to LLVM here (assuming LLVM has a way to let us do that).

[oli-obk]

Oh! yea we should totally fix that. Not sure how to do it for partially initialized aggregates, but we should at least cover the fully uninit case.

[erikdesjardins]

NB: while #83698 fixes this issue as written, it likely does not fix the arrayvec regression, since ArrayVec { xs: MaybeUninit::uninit().assume_init(), len: 0 } is only partially uninit (see #83698 description).

[rodrimati1992]

@erikdesjardins How so? Only the MaybeUninit is a constant. ArrayVec::new_const called in a non-const context should not have any problems with #83698

Which is to say that the two functions below should generate the same code:

fn foo() -> ArrayVec<u8, 1000>{
    ArrayVec::new() 
}
fn bar() -> ArrayVec<u8, 1000> {
    ArrayVec::new_const() 
}

Them not being equivalent was the motivation for the existence of new_const.