Add more safety requirements for Allocator impls#156544
Open
theemathas wants to merge 1 commit into
Open
Conversation
rustbot
added
S-waiting-on-review
Contributor
Author
|
There's text immediately after my edits that address moving the allocator. An allocator must not invalidate its allocations upon moving. |
An `Allocator` implementation is now allowed to invalidate its
allocations when the allocator is mutated or when a lifetime in the
allocator type expires.
Mutation of an `Allocator` should sensibly be allowed to invalidate its
allocations. For example, the `bumpalo` crates has a `Bump::reset`
method that takes `&mut self` and invalidates all past allocations.
Accesses via `&` still must not invalidate past allocations since,
for example, `Box` provides `&` access to the allocator.
The "lifetime expiry" clause closes a hole/ambiguity on when an
allocator is considered to be "dropped" if it does not have a
destructor. Additionally, this clause matches what is required for
`Box::into_pin` and `{Rc, Arc}::pin` to be sound. (Those methods have an
`A: 'static` bound to prevent allocating via a `&MyAllocator` and then
running `MyAllocator`'s destructor.)
theemathas
force-pushed
the
more-allocator-docs
branch
from
5f2bc9f to
459726c
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
An
Allocatorimplementation is now allowed to invalidate its allocations when the allocator is mutated or when a lifetime in the allocator type expires.Mutation of an
Allocatorshould sensibly be allowed to invalidate its allocations. For example, thebumpalocrates has aBump::resetmethod that takes&mut selfand invalidates all past allocations. Accesses via&still must not invalidate past allocations since, for example,Boxprovides&access to the allocator.The "lifetime expiry" clause closes a hole/ambiguity on when an allocator is considered to be "dropped" if it does not have a destructor. Additionally, this clause matches what is required for
Box::into_pinand{Rc, Arc}::pinto be sound. (Those methods have anA: 'staticbound to prevent allocating via a&MyAllocatorand then runningMyAllocator's destructor.)r? libs-api