-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
split MaybeUninit into several features, expand docs a bit #58468
Conversation
r? @shepmaster (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; seems like a good partition except for one thing.
r? @Centril I think this is a good step allowing us to do incremental progress in a reasonable way... ...As such, r=me with green travis. If team members disagree with this incremental approach, feel free to r-. |
@bors r+ |
📌 Commit 95ef9b4 has been approved by |
split MaybeUninit into several features, expand docs a bit This splits the `maybe_uninit` feature gate into several: * `maybe_uninit` for what we will hopefully stabilize soon-ish. * `maybe_uninit_ref` for creating references into `MaybeUninit`, for which the rules are not yet clear. * `maybe_uninit_slice` for handling slices of `MaybeUninit`, which needs more API design work. * `maybe_uninit_array` for creating arrays of `MaybeUninit` using a macro (because we don't have rust-lang#49147 yet). Is that an okay thing to do? The goal is to help people avoid APIs we do not want to stabilize yet. I used this to make sure rustc itself does not use `get_ref` and `get_mut`. I also extended the docs to advise against uninitialized integers -- again this is something for which the rules are still being discussed.
Rollup of 19 pull requests Successful merges: - #57929 (Rustdoc remove old style files) - #57981 (Fix #57730) - #58074 (Stabilize slice_sort_by_cached_key) - #58196 (Add specific feature gate error for const-unstable features) - #58293 (Remove code for updating copyright years in generate-deriving-span-tests) - #58306 (Don't default on std crate when manipulating browser history) - #58359 (librustc_mir: use ? in impl_snapshot_for! macro) - #58395 (Instant::checked_duration_since) - #58429 (fix Box::into_unique effecitvely transmuting to a raw ptr) - #58433 (Update which libcore/liballoc tests Miri ignores, and document why) - #58438 (Use posix_spawn_file_actions_addchdir_np when possible) - #58440 (Whitelist the ARM v6 target-feature) - #58448 (rustdoc: mask `compiler_builtins` docs) - #58468 (split MaybeUninit into several features, expand docs a bit) - #58477 (Fix the syntax error in publish_toolstate.py) - #58479 (compile-pass test for #53606) - #58489 (Fix runtime error in generate-keyword-tests) - #58496 (Fix documentation for std::path::PathBuf::pop) - #58509 (Notify myself when Clippy toolstate changes)
Rollup of 19 pull requests Successful merges: - #57929 (Rustdoc remove old style files) - #57981 (Fix #57730) - #58074 (Stabilize slice_sort_by_cached_key) - #58196 (Add specific feature gate error for const-unstable features) - #58293 (Remove code for updating copyright years in generate-deriving-span-tests) - #58306 (Don't default on std crate when manipulating browser history) - #58359 (librustc_mir: use ? in impl_snapshot_for! macro) - #58395 (Instant::checked_duration_since) - #58429 (fix Box::into_unique effecitvely transmuting to a raw ptr) - #58433 (Update which libcore/liballoc tests Miri ignores, and document why) - #58438 (Use posix_spawn_file_actions_addchdir_np when possible) - #58440 (Whitelist the ARM v6 target-feature) - #58448 (rustdoc: mask `compiler_builtins` docs) - #58468 (split MaybeUninit into several features, expand docs a bit) - #58479 (compile-pass test for #53606) - #58489 (Fix runtime error in generate-keyword-tests) - #58496 (Fix documentation for std::path::PathBuf::pop) - #58509 (Notify myself when Clippy toolstate changes) - #58521 (Fix tracking issue for error iterators)
This splits the
maybe_uninit
feature gate into several:maybe_uninit
for what we will hopefully stabilize soon-ish.maybe_uninit_ref
for creating references intoMaybeUninit
, for which the rules are not yet clear.maybe_uninit_slice
for handling slices ofMaybeUninit
, which needs more API design work.maybe_uninit_array
for creating arrays ofMaybeUninit
using a macro (because we don't have Tracking issue for RFC 2203, "Constants in array repeat expressions" #49147 yet).Is that an okay thing to do? The goal is to help people avoid APIs we do not want to stabilize yet. I used this to make sure rustc itself does not use
get_ref
andget_mut
.I also extended the docs to advise against uninitialized integers -- again this is something for which the rules are still being discussed.