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

Partially stabilize maybe_uninit_extra #92768

Merged
merged 1 commit into from
Jan 14, 2022

Conversation

ojeda
Copy link
Contributor

@ojeda ojeda commented Jan 11, 2022

This covers:

impl<T> MaybeUninit<T> {
    pub unsafe fn assume_init_read(&self) -> T { ... }
    pub unsafe fn assume_init_drop(&mut self) { ... }
}

It does not cover the const-ness of write under const_maybe_uninit_write nor the const-ness of assume_init_read (this commit adds const_maybe_uninit_assume_init_read for that).

FCP: #63567 (comment).

Signed-off-by: Miguel Ojeda ojeda@kernel.org

This covers:

    impl<T> MaybeUninit<T> {
        pub unsafe fn assume_init_read(&self) -> T { ... }
        pub unsafe fn assume_init_drop(&mut self) { ... }
    }

It does not cover the const-ness of `write` under
`const_maybe_uninit_write` nor the const-ness of
`assume_init_read` (this commit adds
`const_maybe_uninit_assume_init_read` for that).

FCP: rust-lang#63567 (comment).

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 11, 2022
@Mark-Simulacrum
Copy link
Member

It looks like the FCP included the const-ness of MaybeUninit::write -- was that excluded for a reason?

#63567 (comment)

@jhpratt
Copy link
Member

jhpratt commented Jan 12, 2022

Not the person who created the PR, but &mut parameters aren't permitted in const fn on stable. I would imagine some lint would fire if we were to try to stabilize it as-is.

MaybeUninit::assume_init_read() shouldn't have any blockers to be const fn, but at the same time it wasn't part of the FCP.

@Mark-Simulacrum
Copy link
Member

Ah, ok. That makes sense.

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jan 12, 2022

📌 Commit 8680a44 has been approved by Mark-Simulacrum

@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 Jan 12, 2022
@ojeda
Copy link
Contributor Author

ojeda commented Jan 12, 2022

Not the person who created the PR, but &mut parameters aren't permitted in const fn on stable. I would imagine some lint would fire if we were to try to stabilize it as-is.

Exactly, plus assume_init_mut is not const-stable. Given we only use the non-const bits in the kernel (so far, at least), I thought it was worth getting this part in at least.

MaybeUninit::assume_init_read() shouldn't have any blockers to be const fn, but at the same time it wasn't part of the FCP.

I did not try since it was not part of the FCP, but from a quick test, we would need const_ptr_read.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jan 14, 2022
… r=Mark-Simulacrum

Partially stabilize `maybe_uninit_extra`

This covers:

```rust
impl<T> MaybeUninit<T> {
    pub unsafe fn assume_init_read(&self) -> T { ... }
    pub unsafe fn assume_init_drop(&mut self) { ... }
}
```

It does not cover the const-ness of `write` under `const_maybe_uninit_write` nor the const-ness of `assume_init_read` (this commit adds `const_maybe_uninit_assume_init_read` for that).

FCP: rust-lang#63567 (comment).

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jan 14, 2022
… r=Mark-Simulacrum

Partially stabilize `maybe_uninit_extra`

This covers:

```rust
impl<T> MaybeUninit<T> {
    pub unsafe fn assume_init_read(&self) -> T { ... }
    pub unsafe fn assume_init_drop(&mut self) { ... }
}
```

It does not cover the const-ness of `write` under `const_maybe_uninit_write` nor the const-ness of `assume_init_read` (this commit adds `const_maybe_uninit_assume_init_read` for that).

FCP: rust-lang#63567 (comment).

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This was referenced Jan 14, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 14, 2022
…askrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#92045 (Don't fall back to crate-level opaque type definitions.)
 - rust-lang#92381 (Suggest `return`ing tail expressions in async functions)
 - rust-lang#92768 (Partially stabilize `maybe_uninit_extra`)
 - rust-lang#92810 (Deduplicate box deref and regular deref suggestions)
 - rust-lang#92818 (Update documentation for doc_cfg feature)
 - rust-lang#92840 (Fix some lints documentation)
 - rust-lang#92849 (Clippyup)
 - rust-lang#92854 (Use the updated Rust logo in rustdoc)
 - rust-lang#92864 (Fix a missing dot in the main item heading)

Failed merges:

 - rust-lang#92838 (Clean up some links in RELEASES)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 558da93 into rust-lang:master Jan 14, 2022
@rustbot rustbot added this to the 1.60.0 milestone Jan 14, 2022
@ojeda ojeda deleted the stabilize-maybe_uninit_extra branch January 14, 2022 20:49
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 13, 2023
…it_assume_init_read, r=dtolnay

Stabilize `const_maybe_uninit_assume_init_read`

AFAICT the only reason this was not included in the `maybe_uninit_extra` stabilization was because `ptr::read` was unstable (rust-lang#92768 (comment)), which has since been stabilized in 1.71.

Needs a separate FCP from the [original `maybe_uninit_extra` one](rust-lang#63567 (comment)).

Tracking issue: rust-lang#63567
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Oct 14, 2023
…_init_read, r=dtolnay

Stabilize `const_maybe_uninit_assume_init_read`

AFAICT the only reason this was not included in the `maybe_uninit_extra` stabilization was because `ptr::read` was unstable (rust-lang/rust#92768 (comment)), which has since been stabilized in 1.71.

Needs a separate FCP from the [original `maybe_uninit_extra` one](rust-lang/rust#63567 (comment)).

Tracking issue: #63567
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.

6 participants