-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rename Alloc
to AllocRef
#68529
Rename Alloc
to AllocRef
#68529
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
Changes themselves look good, but let's r? @Amanieu as this probably needs some libs signoff |
I think the documentation for the
cc @rust-lang/libs |
Sounds reasonable, I will adjust the docs! |
be79dc7
to
61e9667
Compare
@bors r+ |
📌 Commit 61e9667 has been approved by |
Rename `Alloc` to `AllocRef` The allocator-wg has decided to merge this change upstream in rust-lang/wg-allocators#8 (comment). This renames `Alloc` to `AllocRef` because types that implement `Alloc` are a reference, smart pointer, or ZSTs. It is not possible to have an allocator like `MyAlloc([u8; N])`, that owns the memory and also implements `Alloc`, since that would mean, that moving a `Vec<T, MyAlloc>` would need to correct the internal pointer, which is not possible as we don't have move constructors. For further explanation please see rust-lang/wg-allocators#8 (comment) and the comments after that one. Additionally it clarifies the semantics of `Clone` on an allocator. In the case of `AllocRef`, it is clear that the cloned handle still points to the same allocator instance, and that you can free data allocated from one handle with another handle. The initial proposal was to rename `Alloc` to `AllocHandle`, but `Ref` expresses the semantics better than `Handle`. Also, the only appearance of `Handle` in `std` are for windows specific resources, which might be confusing.
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
Required to land rust-lang/rust#68529. Please see that PR for details. The CI is expected to fail until the PR is landed.
In order to workaround the circular submodule dependencies, I re-added the |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Is it really necessary to create a full copy of the trait? Couldn't you simply re-export the trait under the name |
Oh, I didn't know |
Actually |
Currently have a local test running. Will push it with |
f1afe62
to
7ca25db
Compare
@bors r+ |
📌 Commit 7ca25db has been approved by |
Rename `Alloc` to `AllocRef` The allocator-wg has decided to merge this change upstream in rust-lang/wg-allocators#8 (comment). This renames `Alloc` to `AllocRef` because types that implement `Alloc` are a reference, smart pointer, or ZSTs. It is not possible to have an allocator like `MyAlloc([u8; N])`, that owns the memory and also implements `Alloc`, since that would mean, that moving a `Vec<T, MyAlloc>` would need to correct the internal pointer, which is not possible as we don't have move constructors. For further explanation please see rust-lang/wg-allocators#8 (comment) and the comments after that one. Additionally it clarifies the semantics of `Clone` on an allocator. In the case of `AllocRef`, it is clear that the cloned handle still points to the same allocator instance, and that you can free data allocated from one handle with another handle. The initial proposal was to rename `Alloc` to `AllocHandle`, but `Ref` expresses the semantics better than `Handle`. Also, the only appearance of `Handle` in `std` are for windows specific resources, which might be confusing. Blocked on rust-lang/miri#1160
☀️ Test successful - checks-azure |
Required to land rust-lang/rust#68529. Please see that PR for details. The CI is expected to fail until the PR is landed.
Rename `Alloc` to `AllocRef` Required to land rust-lang/rust#68529. Please see that PR for details. The CI is expected to fail until the PR is landed.
Remove `Alloc` in favor of `AllocRef` `AllocRef` was reexported as `Alloc` in rust-lang#68529 in order to not break toolstate in the week before the next stable release. r? @Amanieu
The allocator-wg has decided to merge this change upstream in rust-lang/wg-allocators#8 (comment).
This renames
Alloc
toAllocRef
because types that implementAlloc
are a reference, smart pointer, or ZSTs. It is not possible to have an allocator likeMyAlloc([u8; N])
, that owns the memory and also implementsAlloc
, since that would mean, that moving aVec<T, MyAlloc>
would need to correct the internal pointer, which is not possible as we don't have move constructors.For further explanation please see rust-lang/wg-allocators#8 (comment) and the comments after that one.
Additionally it clarifies the semantics of
Clone
on an allocator. In the case ofAllocRef
, it is clear that the cloned handle still points to the same allocator instance, and that you can free data allocated from one handle with another handle.The initial proposal was to rename
Alloc
toAllocHandle
, butRef
expresses the semantics better thanHandle
. Also, the only appearance ofHandle
instd
are for windows specific resources, which might be confusing.Blocked on rust-lang/miri#1160