Implement a "MaybeUninit" and use it conditionally (0.4.x version) #114
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
This seems like a trivial test, but since it can fail, it shows us that we don't have a sound implementation yet.
Owner
Author
|
This will be merged into master after 0.4, and we'll make a release with similar code for 0.5.x release series too. Thougths on updating 0.4.x? It's quite widely used, so it would be good to put a sounder implementation out there, if only on nightly. We're doing the best we can with stable. |
bluss
force-pushed
the
maybe-uninit-0.4
branch
2 times, most recently
from
15e1430 to
433d40e
Compare
Use a build script to detect if we can use MaybeUninit or NoDrop. Enabling unstable features automatically is not ideal, but since it's a soundness issue we should do it. Use a MaybeUninit-like union on nightly when we can. We use a feature detection script in build.rs, so that we also go back to the fallback if the unstable feature changes in an unexpected way. We need to continue to use NoDrop for best working stable implementation, but we eagerly use our union solution where we can, currently only in nightlies. Rustc feature probe code written by Josh Stone (cuviper), taken from num-bigint.
We can't fix this properly (MaybeUninit with a union) until we change the user visible API (we need to require that A: Copy. As a temporary solution for arrayvec version 0.4.*, we use zeroed to initialize an array of bytes, instead of using uninitialized. This may have a negative performance impact, but the fix is to upgrade to future arrayvec 0.5.
bluss
force-pushed
the
maybe-uninit-0.4
branch
from
433d40e to
d395a01
Compare
This was referenced Dec 16, 2018
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.
This change is for the 0.4.x release series of arrayvec,
not master.
Implement a "MaybeUninit" and use it conditionally
Use a build script to detect if we can use MaybeUninit or NoDrop.
Enabling unstable features automatically is not ideal, but since it's
a soundness issue we should do it.
Use a MaybeUninit-like union on nightly when we can. We use a feature
detection script in build.rs, so that we also go back to the fallback if
the unstable feature changes in an unexpected way.
We need to continue to use NoDrop for best working stable
implementation, but we eagerly use our union solution where we can,
currently only in nightlies.
Rustc feature probe code written by @cuviper, taken from num-bigint.
Remove use of uninitialized in ArrayString
We can't fix this properly (MaybeUninit with a union) until we change
the user visible API (we need to require that A: Copy.
As a temporary solution for arrayvec version 0.4.*, we use zeroed to
initialize an array of bytes, instead of using uninitialized. This may
have a negative performance impact, but the fix is to upgrade to future
arrayvec 0.5.
This also changes the
use_unionfeature to do nothing. This isallowed, as has been indicated in the feature description in docs.
There are no user visible API changes but the size of ArrayVec types may
change due to the enabling of the MaybeUninit feature.
Closes #86 (now obsolete)