Remove uses of nightly maybe_uninit_* features
#238
+51
−11
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Implementation is copied almost exactly from the unstable code in core. Includes an unused `_mut` version of the shim because why not. Might be handy.
Replaces the single use of `alloc_uninit().transpose()` with a dedicated method for allocating an array. Unfortunately a shim for `transpose` could not be directly created since it relies on the `transmute_unchecked()` intrinsic to bypass a `size_of` limitation, but intrinsics are "perma-unstable."
lhecker
reviewed
May 23, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Continuing with #44, this PR will remove the dependency on three additional nightly features.
[MaybeUninit<T>]::assume_init_ref()have been replaced with a shim insrc/helpers.rsthat just contains the exact sametransmutecall found in the nightly implementation ofassume_init_ref(). This should be totally safe, relatievly speaking, since the two types have the exact same layout and the transmute relies on the same initialization invariants that makeassume_init_ref()unsafe anyways.MaybeUninit<[T; N]>::transpose() -> [MaybeUninit<T>; N], since the implementation used by the stdlib works by usingintrinsics::transmute_unchecked, which omits thesize_ofcheck between arguments. It seems that a regular transmute is not quite smart enough to realize that the two have the same size, resulting in a warning about how one of the types have a variable size (even though both are parameterized by a constantN?). Instead, I simply added a new method on theArenathat will return a[MaybeUninit<T>; N]directly using the same logic as the surrounding allocator methods. Hopefully that doesn't result in too noticeable an increase to binary size. 🤞🏻Still planned for this PR (probably tomorrow or over the weekend):
maybe_uninit_fill. It's only used in one spot to fill a slice ofMaybeUninit<Option<&RefCell<Node>>>with a bunch ofNones. Making a general replacement ofwrite_fillmight be a bit annoying (barring just copying directly from the nightly impl. again), but I think a better approach would be to make use ofDefaultin this particular case to fill the slice ofMaybeUninit<Option<T>>withOption<T>::Nones.Like the
transpose()change, I'm a bit apprehensive on what the code-gen and performance implications of the possible approaches will be here, though. I'm a little worried that writing any sort of loop over the slice will result in something slower than what's in the stdlib. Overall, I'd like to try and avoid doing too much "oh, just copy the nightly implementation directly from the stdlib", if possible. That feels like it kind of defeats the purpose of trying to replace nightly APIs with stable ones. 😅As before, looking forward to feedback and discussion. Let me know if the comments are too long! 😝