use const array repeat expressions for uninit_array

[RalfJung]

With a first implementation of #49147 having landed, we can make this macro nicer and phase it out with the next bootstrap bump.

However, to make this work, we have to mark MaybeUninit::uninit() as promotable. I do feel uneasy about promoting stuff involving uninitialized memory, but OTOH no operation on MaybeUninit is promotable, so maybe this is okay?

r? @oli-obk@eddyb

[bjorn3]

Does this have support for feature gating?

[RalfJung]

I don't think so. @oli-obk ?

[bjorn3]

Explicitly puting the MaybeUninit::uninit() seems to work. That would make this unnecessary.

https://play.integer32.com/?version=stable&mode=debug&edition=2018&gist=71886586e61fc9a677ce120c825c4aae

[RalfJung]

That playground does not load here? I just get a blank page. The one at https://play.rust-lang.org/ works.

Can you paste the code you are suggesting here in GitHub?

[bjorn3]

Yeah the playground at integer32 broken for me too.

The code was:

use std::mem::MaybeUninit;fnmain(){constA:MaybeUninit<u8> = MaybeUninit::uninit();let a_arr = [A;2];}

But looking at the optimized llvm ir, it seems that llvm emits a memset with zero, instead of keeping it uninitialized in case of:

use std::mem::MaybeUninit;pubfnabc() -> [MaybeUninit<u8>;16]{constA:MaybeUninit<u8> = MaybeUninit::uninit();let a_arr = [A;16];//unsafe { std::mem::uninitialized() };
a_arr
}

[RalfJung]

MaybeUninit<u8> is Copy, so this does not really test the new code paths anyway.

But yes, you can probably "trigger" promotion as usual with a manual const.

[Centril]

However, to make this work, we have to mark MaybeUninit::uninit() as promotable. I do feel uneasy about promoting stuff involving uninitialized memory, but OTOH no operation on MaybeUninit is promotable, so maybe this is okay?

This should not be necessary. You can use a perma-unstable associated constant instead:

impl<T>MaybeUninit<T>{#[unstable( feature = "internal_uninit_const", issue = "0", reason = "hack to work around promotability",)]pubconstUNINIT:Self = Self::uninit();}fnfoo<T>(){let x = [MaybeUninit::<T>::UNINIT;5];// OK.}

(I checked that this idea works on master as of the time of writing this comment.)

[eddyb]

@Centril The goal is to remove the macro ASAP.

On Zulip I suggested we treat zero-argument const fns like consts and always promote them.

[RalfJung]

Ah yes an explicit constant should do it, true. That won't help users outside libstd but that is a separate concern.

On Zulip I suggested we treat zero-argument const fns like consts and always promote them.

I don't think I am a fan of expanding the scope of promotion in any way. const and nullary const fn are not equivalent in every way. For example, we do a validity check on the value of a const, but we don't do anything like that for nullary const fn. The rules for what code is allowed are also not the same for both.

[RalfJung]

Okay, this no longer makes MaybeUninit::uninit promotable.

[RalfJung]

tidy error: /checkout/src/libcore/mem/maybe_uninit.rs:256: malformed stability attribute: missing feature key

But there is a feature key. Is tidy's parser too short-sighted to handle multi-line attributes?

[eddyb]

For example, we do a validity check on the value of a const, but we don't do anything like that for nullary const fn. The rules for what code is allowed are also not the same for both.

No reason we couldn't! Or even for any sub-computation that doesn't depend on arguments.
EDIT: would be interesting to do some crater run to see if anyone wrote some nullary const fns that wouldn't pass const validation.

[Centril]

That won't help users outside libstd but that is a separate concern.

To work around the lack of {-# LANGUAGE ScopedTypeVariables #-} when in a generic setting, other crates can use a slightly modified version of the hack which involves an extension trait that contains the associated constant. It's not exactly pretty, but it will get the job done 😝.

[Centril]

I'm happy with this so r=me rollup if you like or wait for Oliver's review otherwise, up to you. ;)

[RalfJung]

@bors r=Centril rollup

[bors]

📌 Commit f3abbf7 has been approved by Centril

[bors]

🌲 The tree is currently closed for pull requests below priority 1500, this pull request will be tested once the tree is reopened