]> git.lizzy.rs Git - rust.git/commit - src/tools/miri
Auto merge of #68529 - TimDiekmann:rename-alloc, r=Amanieu
authorbors <bors@rust-lang.org>
Tue, 28 Jan 2020 08:44:20 +0000 (08:44 +0000)
committerbors <bors@rust-lang.org>
Tue, 28 Jan 2020 08:44:20 +0000 (08:44 +0000)
commitb181835a6bacfa449f55d46764a10e25d1c471dc
tree7a5af02ac37fe47a4a0761fa5662caa062cb6a60
parent82018665a5f2c34566b30c1b0b5a27c72d3b9a68
parent7ca25db8162128808714f536fa993aefcf6a2239
Auto merge of #68529 - TimDiekmann:rename-alloc, r=Amanieu

Rename `Alloc` to `AllocRef`

The allocator-wg has decided to merge this change upstream in https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-577122958.

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 https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-489464843 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 https://github.com/rust-lang/miri/pull/1160