Skip to content
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

Import Alloc and Layout explicitly #1160

Closed
wants to merge 1 commit into from

Conversation

TimDiekmann
Copy link
Member

This is required for rust-lang/rust#68529 to land. Alloc will be renamed to AllocRef, Alloc will be added as #[doc(hidden)] trait, until AllocRef is merged. Then #1154 can be merged, and Alloc can be removed. When using a wildcard import, the CI of miri will fail then.

bors added a commit to rust-lang/rust that referenced this pull request 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
@RalfJung
Copy link
Member

So, we don't need this adjustment after all? Or only later, when the Alloc reexport gets removed?

Avoiding glob imports also seems reasonable, so I'd be fine to land this if you want to reopen.

@TimDiekmann
Copy link
Member Author

I have to adjust a few tests in the future anyway. With reexporting AllocRef as Alloc this isn't needed, but we can merge this anyway :)

@TimDiekmann TimDiekmann reopened this Jan 29, 2020
@TimDiekmann
Copy link
Member Author

Closed in favor of #1154

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants