Skip to content

Allocators in BTreeMap and BTreeSet need more work #161678

Description

@maxdexh

In #157428, we banned allocators from unwinding out of their drop to fix #159334 and its related issues. We also introduced AllocatorClone to fix #156920. In #161684, we replaced the Allocator + Clone bounds with AllocatorClone as a short-term solution.

However, the allocators are still cloned at every recursive call site, which was originally done to fix regressions with using references for this, since ZST allocators (like the most important allocator, Global), had measureable overhead. However, for non-Copy allocators, this is completely unreasonable. Even the destructor of BTreeMap clones around the allocator recursively, so there is no way to use BTreeMap without AllocatorClone at all currently.

We should probably come up with another solution that allows ZSTs to be passed by-value, while expensive-to-clone allocators can be passed by reference, perhaps through some kind of unsafe trait AllocatorShare { type Share<'a>: Allocator; fn share_alloc(&self) -> Self::Share<'_>; }. This would also allow something like Box<Arc<&Arc<A>>> to be passed around as A::Share, since it can defer recursively. However it has its own design problems.

Discussion on zulip

@rustbot label A-allocators requires-nightly -I-unsound A-collections -C-bug C-discussion

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-allocatorsArea: Custom and system allocatorsA-collectionsArea: `std::collections`C-discussionCategory: Discussion or questions that doesn't represent real issues.T-libsRelevant to the library team, which will review and decide on the PR/issue.requires-nightlyThis issue requires a nightly compiler in some way. When possible, use a F-* label instead.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions