about summary refs log tree commit diff
path: root/src/librustc_codegen_utils/codegen_backend.rs
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2020-01-28 08:44:20 +0000
committerbors <bors@rust-lang.org>2020-01-28 08:44:20 +0000
commitb181835a6bacfa449f55d46764a10e25d1c471dc (patch)
tree7a5af02ac37fe47a4a0761fa5662caa062cb6a60 /src/librustc_codegen_utils/codegen_backend.rs
parent82018665a5f2c34566b30c1b0b5a27c72d3b9a68 (diff)
parent7ca25db8162128808714f536fa993aefcf6a2239 (diff)
downloadrust-b181835a6bacfa449f55d46764a10e25d1c471dc.tar.gz
rust-b181835a6bacfa449f55d46764a10e25d1c471dc.zip
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
Diffstat (limited to 'src/librustc_codegen_utils/codegen_backend.rs')
0 files changed, 0 insertions, 0 deletions