-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
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.