Question: Is the Clone bound on allocator in A: Allocator + Clone really necessary?

Hey :)

I am using the nightly allocator_api with a custom allocator. To guarantee safety in my setup, the allocator I have is not Clone.

This worked with collections in alloc, but hashbrown's allocator needs to be Clone. I tracked this requirement down to a single function: RawTableInner::prepare_resize, which has a couple of clients.

Hashbrown's codebase is way above my paygrade, but the general question is: is this just a limitation of the current implementation, or will it never be possible to remove the bound? Naturally, the allocator needs to be Clone, if the collection wants to implement Clone, but does it need to be Clone otherwise?

Start at RawTableInner::prepare_resize and trace the couple of clients identified in the issue, then compare their allocator requirements with the nightly allocator_api collections in alloc. Determine whether the Clone bound is required by those call paths or only by the current implementation; done means a documented conclusion or a focused change with tests showing non-Clone allocators work where appropriate.