Uh oh!
There was an error while loading. Please reload this page.
Rename Alloc to AllocRef - #68529
Conversation
rust-highfive
commented
Jan 25, 2020
(rust_highfive has picked a reviewer for you, use r? to override) |
Mark-Simulacrum
commented
Jan 25, 2020
Changes themselves look good, but let's r? @Amanieu as this probably needs some libs signoff |
Amanieu
commented
Jan 26, 2020
I think the documentation for the
cc @rust-lang/libs |
TimDiekmann
commented
Jan 26, 2020
Sounds reasonable, I will adjust the docs! |
be79dc7 to
61e9667CompareAmanieu
commented
Jan 26, 2020
@bors r+ |
bors
commented
Jan 26, 2020
📌 Commit 61e9667 has been approved by |
bors
commented
Jan 26, 2020
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.
rust-highfive
commented
Jan 26, 2020
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 |
bors
commented
Jan 26, 2020
💔 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.
TimDiekmann
commented
Jan 27, 2020
In order to workaround the circular submodule dependencies, I re-added the |
rust-highfive
commented
Jan 27, 2020
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 |
TimDiekmann
commented
Jan 27, 2020
Oh, I didn't know |
Amanieu
commented
Jan 27, 2020
Actually |
Currently have a local test running. Will push it with |
f1afe62 to
7ca25dbCompareAmanieu
commented
Jan 27, 2020
@bors r+ |
bors
commented
Jan 27, 2020
📌 Commit 7ca25db has been approved by |
bors
commented
Jan 28, 2020
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
bors
commented
Jan 28, 2020
☀️ Test successful - checks-azure |
Uh oh!
There was an error while loading. Please reload this page.
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
AlloctoAllocRefbecause types that implementAllocare 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
Cloneon 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
AlloctoAllocHandle, butRefexpresses the semantics better thanHandle. Also, the only appearance ofHandleinstdare for windows specific resources, which might be confusing.Blocked on rust-lang/miri#1160