Skip to content

allocator: refactor for stabilisation - #157428

Open
nia-e wants to merge 2 commits into
rust-lang:mainfrom
nia-e:allocator-refactor
Open

allocator: refactor for stabilisation#157428
nia-e wants to merge 2 commits into
rust-lang:mainfrom
nia-e:allocator-refactor

Conversation

@nia-e

@nia-e nia-e commented Jun 4, 2026

Copy link
Copy Markdown
Member

View all comments

Adds my current proposal per the doc in #156882 and follow-up Zulip conversations (notably for dyn-compat) unstably.

r? libs

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 4, 2026
@nia-e nia-e added the A-allocators Area: Custom and system allocators label Jun 4, 2026
Comment thread library/core/src/alloc/mod.rs Outdated
@rust-log-analyzer

This comment has been minimized.

qaijuang

This comment was marked as resolved.

@rust-log-analyzer

This comment has been minimized.

@nia-e

nia-e commented Jun 4, 2026

Copy link
Copy Markdown
Member Author

Note that the no-panic bounds introduced close #156490 and #155746. However, if we want to relax them in the future, we may need to adjust our collection types to be more resilient.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

Comment thread library/alloc/src/str.rs Outdated
Comment thread library/core/src/alloc/mod.rs Outdated
Comment thread library/core/src/alloc/mod.rs Outdated
Comment thread library/core/src/alloc/mod.rs Outdated
Comment thread library/core/src/alloc/mod.rs Outdated
Comment thread library/core/src/alloc/mod.rs Outdated
Comment thread library/core/src/alloc/mod.rs Outdated
Comment thread library/core/src/alloc/mod.rs Outdated
Comment thread library/core/src/alloc/mod.rs Outdated
Comment thread library/core/src/alloc/mod.rs Outdated
Comment thread library/core/src/alloc/mod.rs Outdated
@clarfonthey

Copy link
Copy Markdown
Contributor

@rustbot author

(mostly so you can more clearly signal when you think things are ready; I've commented here already so I'll see any additional changes for review as they're made)

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 4, 2026
Comment thread library/core/src/alloc/mod.rs
@rust-log-analyzer

This comment has been minimized.

@@ -74,7 +74,8 @@ impl fmt::Display for AllocError {
/// * Moving, subtyping, unsize-coercing, or trait-upcasting an allocator does not change
/// what the allocator is equivalent to.
/// * Copying or cloning allocator results in an allocator that's

@maxdexh maxdexh Jul 28, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we require copies to be equivalent? If so, this relies on the orphan rule for Copy (which might be fine since Copy is special), but I'm confused because the AllocatorClone docs do not talk about requirements for copies.

View changes since the review

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought there was wording to the effect of "if Copy could be implemented for an AllocatorClone type, that must also obey its semantics", but if not I will add it. ty!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by "could"? Can we rely on Drop + Copy being disallowed for soundness? I think we didn't discuss this part enough 😅

Comment thread library/core/src/alloc/mod.rs Outdated
Comment thread library/core/src/alloc/mod.rs
@rust-bors

This comment has been minimized.

@rustbot

This comment has been minimized.

@nia-e

nia-e commented Aug 4, 2026

Copy link
Copy Markdown
Member Author

(apologies for the squash-and-rebase, nothing meaningful to review should have changed between force-pushes)

@rust-log-analyzer

This comment has been minimized.

Comment on lines -2170 to +2179
if self.len() > source.len() {
self.split_off(source.len());
}
for (elem, source_elem) in self.iter_mut().zip(&mut source_iter) {
for elem in self.iter_mut() {
let Some(source_elem) = source_iter.next() else {
break;
};
elem.clone_from(source_elem);
}
while self.len() > source.len() {
self.pop_back();
}

@clarfonthey clarfonthey Aug 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unreasonably upset at this code just because of how limited the LinkedList API is. Should be doable, but isn't… :(

View changes since the review

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

samesies qwq

Comment thread library/alloc/src/boxed.rs
Comment thread library/alloc/src/boxed.rs
Comment thread library/alloc/src/str.rs Outdated
Comment thread library/core/src/alloc/mod.rs
Comment thread library/core/src/alloc/mod.rs
Comment thread library/core/src/alloc/mod.rs
@Darksonn

Darksonn commented Aug 6, 2026

Copy link
Copy Markdown
Member

This PR seems to make multiple unrelated changes. Is it possible to get an overview of all the changes it's making? Or even better, perhaps we could split out this into multiple PRs so that we can merge the things we agree on now, without blocking them on the things still being discussed?

@nia-e

nia-e commented Aug 6, 2026

Copy link
Copy Markdown
Member Author

I'm unsure how i'd go about splitting this up, since many of the miscellaneous library changes are necessary for the API to be sound. (ofc, if you have an idea that'd lighten the review burden, i'm happy to do it and i think @clarfonthey would be relieved too)

In short, the changes made are:

  • split out requirements from Allocator into the 2 new traits StaticAllocator and AllocatorClone, as not all allocators we want to support can obey those semantics
    • StaticAllocator is required for pinning and acting as a global allocator, effectively being a promise that this allocator will never free memory without an explicit deallocate call (and not from e.g. dropping)
    • AllocatorClone promises semantics about what cloning an allocator does, namely that it requires the clone not to unwind and that the new allocator is interchangeable with the old one. this is
  • update std APIs to use these new trait bounds where necessary for soundness
  • implement said traits for std pointer types where doing so is sound, to facilitate using methods bound by them even if the new traits take a longer while to be proposed for stabilisation than the main one (i guess this could be split out?)

i'm quite happy with the fact that (beyond adding the ban on unwinding out of an allocating method or drop) none of this tightens requirements on Allocator implementors at all.

@maxdexh

maxdexh commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Also, unlike the old allocator api, we think this is sound (modulo some details in the docs we haven't discussed fully) :D

@rust-log-analyzer

This comment has been minimized.

Comment thread library/alloc/src/boxed.rs Outdated
@rust-log-analyzer

This comment has been minimized.

@nia-e nia-e mentioned this pull request Aug 8, 2026
17 tasks
@rust-bors

This comment has been minimized.

yk what we can do btree later

raaaaagh

pain and suffering

*unleaks your box* whats thiSegmentation fault (core dumped)

straight up testing it. and by it,

well, let's just say. "my allocator"

linked and listed

the unnecesary bits? gone. reduced to atoms
@nia-e
nia-e force-pushed the allocator-refactor branch from 791e139 to f4d4ee7 Compare August 9, 2026 15:38
@rustbot

rustbot commented Aug 9, 2026

Copy link
Copy Markdown
Collaborator

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@nia-e

nia-e commented Aug 9, 2026

Copy link
Copy Markdown
Member Author

(squashed & rebased since #56935 conflicted; only change was renaming PinCoerceUnsized to PinSafePointer per that PR)

@rust-log-analyzer

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-allocators Area: Custom and system allocators S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet