-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Less unsafe in the array example of MaybeUninit docs #62634
Conversation
Ah, good point! I like it. The comment before the loop already says "dropping a |
70524b8
to
55e3223
Compare
Oops, I missed the |
Thanks! @bors r+ rollup |
📌 Commit 55e322355b5c5982ef9fee2e7e828ad6a30b7d84 has been approved by |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Uh, branch CI failed. Could you investigate? @bors r- |
55e3223
to
cb3aa4c
Compare
Okay, r=me once CI for this PR is green. @bors delegate+ |
✌️ @llogiq can now approve this pull request |
@bors r+ |
📌 Commit cb3aa4c has been approved by |
Please make sure to designate the reviewer when you are doing this for someone else. @bors r=RalfJung |
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit cb3aa4c has been approved by |
Less unsafe in the array example of MaybeUninit docs I believe this is an acceptable way to initialize elements of `[MaybeUninit<T>; _]` arrays. Miri agrees. Conceptually, we are working at the array level, above the `MaybeUninit`, and as we are replacing it wholesale, this should pose no problem to soundness. And the code is easier to read. r? @RalfJung
Rollup of 14 pull requests Successful merges: - #62103 (Add debug assertions to write_bytes and copy*) - #62405 (Remove never_type feature requirement for exhaustive patterns) - #62491 (Fix Pin urls in Option documentation) - #62533 (Add missing links for CannotReallocInPlace type) - #62634 (Less unsafe in the array example of MaybeUninit docs) - #62639 (Make VaListImpl<'f> invariant over the 'f lifetime) - #62646 (Tweak wording in feature gate errors) - #62662 (add spaces in front of trait requirements in libcore/cell.rs) - #62668 (Fix #62660) - #62673 (miri validation: better error messages for dangling references) - #62680 (Actually call `visit_block_entry` in `DataflowResultsConsumer`) - #62685 (Add info about undefined behavior to as_ref suggestions) - #62689 (Fix typo in RawWaker::new documentation) - #62698 (SGX target: don't pretend to be GNU/Linux to LLVM) Failed merges: r? @ghost
I believe this is an acceptable way to initialize elements of
[MaybeUninit<T>; _]
arrays. Miri agrees. Conceptually, we are working at the array level, above theMaybeUninit
, and as we are replacing it wholesale, this should pose no problem to soundness. And the code is easier to read.r? @RalfJung