Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use const array repeat expressions for uninit_array #62799

Merged
merged 4 commits into from
Jul 22, 2019

Conversation

RalfJung
Copy link
Member

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 19, 2019
@@ -248,6 +248,7 @@ impl<T> MaybeUninit<T> {
/// [type]: union.MaybeUninit.html
#[stable(feature = "maybe_uninit", since = "1.36.0")]
#[inline(always)]
#[rustc_promotable]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this have support for feature gating?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@RalfJung RalfJung Jul 20, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Centril commented Jul 21, 2019

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
Copy link
Member

eddyb commented Jul 21, 2019

@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
Copy link
Member Author

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
Copy link
Member Author

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

@rust-highfive

This comment has been minimized.

@RalfJung
Copy link
Member Author

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
Copy link
Member

eddyb commented Jul 21, 2019

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
Copy link
Contributor

Centril commented Jul 21, 2019

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
Copy link
Contributor

Centril commented Jul 21, 2019

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

@RalfJung
Copy link
Member Author

@bors r=Centril rollup

@bors
Copy link
Contributor

bors commented Jul 21, 2019

📌 Commit f3abbf7 has been approved by Centril

@bors
Copy link
Contributor

bors commented Jul 21, 2019

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

@bors 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 added a commit to Centril/rust that referenced this pull request Jul 22, 2019
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
bors added a commit that referenced this pull request Jul 22, 2019
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
@bors bors merged commit f3abbf7 into rust-lang:master Jul 22, 2019
@RalfJung RalfJung deleted the uninit-array branch July 23, 2019 06:52
@Centril Centril mentioned this pull request Jul 27, 2019
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants