use const array repeat expressions for uninit_array #62799

RalfJung · 2019-07-19T12:48:16Z

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 · 2019-07-19T14:10:47Z

src/libcore/mem/maybe_uninit.rs

@@ -248,6 +248,7 @@ impl<T> MaybeUninit<T> {
    /// [type]: union.MaybeUninit.html
    #[stable(feature = "maybe_uninit", since = "1.36.0")]
    #[inline(always)]
+    #[rustc_promotable]


Does this have support for feature gating?

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

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

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?

Yeah the playground at integer32 broken for me too.

The code was:

use std::mem::MaybeUninit; fn main() { const A: 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; pub fn abc() -> [MaybeUninit<u8>; 16] { const A: MaybeUninit<u8> = MaybeUninit::uninit(); let a_arr = [A; 16]; //unsafe { std::mem::uninitialized() }; a_arr }

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 · 2019-07-21T01:02:12Z

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",
    )]
    pub const UNINIT: Self = Self::uninit();
}

fn foo<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 · 2019-07-21T08:58:02Z

@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 · 2019-07-21T09:34:23Z

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 · 2019-07-21T10:33:42Z

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

RalfJung · 2019-07-21T10:58:26Z

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 · 2019-07-21T11:29:47Z

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 · 2019-07-21T13:48:47Z

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 · 2019-07-21T13:56:12Z

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

RalfJung · 2019-07-21T16:08:19Z

@bors r=Centril rollup

bors · 2019-07-21T16:08:20Z

📌 Commit f3abbf7 has been approved by Centril

bors · 2019-07-21T16:08:21Z

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

@oli-obk

use const array repeat expressions for uninit_array With a first implementation of rust-lang#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

@ghost

Rollup of 14 pull requests Successful merges: - #62709 (Test that maplike FromIter satisfies uniqueness) - #62713 (Stabilize <*mut _>::cast and <*const _>::cast) - #62746 ( do not use assume_init in std::io) - #62787 (Fix typo in src/libstd/net/udp.rs doc comment) - #62788 (normalize use of backticks in compiler messages for libcore/ptr) - #62799 (use const array repeat expressions for uninit_array) - #62810 (normalize use of backticks in compiler messages for librustc_lint) - #62812 (normalize use of backticks in compiler messages for librustc_metadata) - #62832 (normalize use of backticks in compiler messages for librustc_incremental) - #62845 (read: fix doc comment) - #62853 (normalize use of backticks in compiler messages for librustc/hir) - #62854 (Fix typo in Unicode character name) - #62858 (Change wrong variable name.) - #62870 (fix lexing of comments with many \r) Failed merges: r? @ghost

use const array repeat expressions for uninit_array

e074db7

rust-highfive assigned oli-obk Jul 19, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 19, 2019

bjorn3 reviewed Jul 19, 2019

View reviewed changes

avoid uninit_array! macro where it is not needed

ad261f6

RalfJung mentioned this pull request Jul 19, 2019

Tracking issue for RFC 1892, "Deprecate uninitialized in favor of a new MaybeUninit type" #53491

Closed

3 tasks

use a const to hack around promotion limitations

4b47e78

This comment has been minimized.

# to view

tidy is being silly

f3abbf7

RalfJung mentioned this pull request Jul 21, 2019

tidy complains about valid stability attribute #62846

Closed

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 21, 2019

Centril mentioned this pull request Jul 22, 2019

Rollup of 14 pull requests #62873

Merged

bors merged commit f3abbf7 into rust-lang:master Jul 22, 2019

RalfJung deleted the uninit-array branch July 23, 2019 06:52

Centril mentioned this pull request Jul 27, 2019

Add by-value iterator for arrays #62959

Merged

5 tasks

use const array repeat expressions for uninit_array #62799

use const array repeat expressions for uninit_array #62799

Uh oh!

Conversation

RalfJung commented Jul 19, 2019

Uh oh!

bjorn3 Jul 19, 2019

Choose a reason for hiding this comment

Uh oh!

RalfJung Jul 19, 2019

Choose a reason for hiding this comment

Uh oh!

bjorn3 Jul 19, 2019

Choose a reason for hiding this comment

Uh oh!

RalfJung Jul 20, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bjorn3 Jul 20, 2019

Choose a reason for hiding this comment

Uh oh!

RalfJung Jul 20, 2019

Choose a reason for hiding this comment

Uh oh!

Centril commented Jul 21, 2019

Uh oh!

eddyb commented Jul 21, 2019

Uh oh!

RalfJung commented Jul 21, 2019

Uh oh!

RalfJung commented Jul 21, 2019

Uh oh!

This comment has been minimized.

RalfJung commented Jul 21, 2019

Uh oh!

eddyb commented Jul 21, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Centril commented Jul 21, 2019

Uh oh!

Centril commented Jul 21, 2019

Uh oh!

RalfJung commented Jul 21, 2019

Uh oh!

bors commented Jul 21, 2019

Uh oh!

bors commented Jul 21, 2019

Uh oh!

Uh oh!

RalfJung Jul 20, 2019 •

edited

Loading

eddyb commented Jul 21, 2019 •

edited

Loading