Skip to content

allocator: refactor for stabilisation - #157428

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

allocator: refactor for stabilisation#157428
nia-e wants to merge 31 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.

@nia-e

nia-e commented Jul 26, 2026

Copy link
Copy Markdown
Member Author

so, cc @maxdexh @theemathas - do you suspect there will be significantly more soundness bugs to iron out on the core traits? i'd lightly push towards landing this on nightly soonish and adjusting stuff in followup PRs.

in the same spirit, i ditched AllocatorEq since it's more in the realm of "potential future extensions" & isn't necessary right now.

@maxdexh

maxdexh commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

I think the feature is in a great state now, thanks for the awesome work :D

I'll be giving the safety requirements another read and will try to break it again when I get time at the end of next week, but I'm pretty happy with how the API looks right now (and glad that it wasn't stabilized in the old state 😅)

Also if this hits nightly it'll be much easier to work with for me as well, so I'm strongly in favor of that.

@maxdexh

maxdexh commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

Did you plan to add the A: Send + Sync bounds for Arc in this PR or separately?

@theemathas

theemathas commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

Other than the opsem stuff (which I haven't been following at all and therefore don't know the state of), and btree stuff (which is a later problem), I don't think there are other soundness issues. I'll probably have a few more looks at it before stabilization though.

@nia-e

nia-e commented Jul 26, 2026

Copy link
Copy Markdown
Member Author

Did you plan to add the A: Send + Sync bounds for Arc in this PR or separately?

i'd leave that for the PR that actually moves the allocator out of the arc, which would be a blocker for stabilising anything like Arc::new_in

@maxdexh

maxdexh commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

i'd leave that for the PR that actually moves the allocator out of the arc, which would be a blocker for stabilising anything like Arc::new_in

Such a PR will probably be blocked by all the other changes being made to Arc and Rc right now (#132553, which is itself blocked by #141348).

But it's fine if the allocator generic on Arc/Rc stays unstable (I don't like the idea of stabilizing it, but keeping new_in unstable, since people might already start generalizing their APIs)

@nia-e

nia-e commented Jul 26, 2026

Copy link
Copy Markdown
Member Author

the plan is for everything allocator-y about Rc and Arc to stay unstable for now, no worries ^^

@maxdexh

maxdexh commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

Institutional knowledge yay

@nia-e

nia-e commented Jul 26, 2026

Copy link
Copy Markdown
Member Author

see the stabilisation doc on the main stabilisation PR (deets somewhat out of date now, but the plan for what to stabilise hasn't been changed) - i've been trying to avoid making too much of this institutional knowledge :D

@maxdexh

This comment was marked as off-topic.

@rust-log-analyzer

This comment has been minimized.

Comment thread library/alloc/src/collections/linked_list.rs Outdated
@maxdexh

maxdexh commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

For the record, LinkedList is also sensitive to alloc.clone() unwinding. Not filing an issue because I assume this is getting merged soon (unless you want me to file an issue 👀)

@nia-e

nia-e commented Jul 26, 2026

Copy link
Copy Markdown
Member Author

please do file issues for everything distinct! we need to keep track of what's outstanding as we go and stabilise things

@maxdexh

This comment was marked as off-topic.

Comment thread library/alloc/src/collections/linked_list.rs Outdated
@RalfJung

Copy link
Copy Markdown
Member

Other than the opsem stuff (which I haven't been following at all and therefore don't know the state of), and btree stuff (which is a later problem), I don't think there are other soundness issues. I'll probably have a few more looks at it before stabilization though.

Which opsem stuff? There should be none left since we delegated all opsem magic to a hypothetical future NativeAllocator wrapper.

And there's the unleaking problem but not much we can do about that, that just is fundamentally a tricky footgun.

@clarfonthey

Copy link
Copy Markdown
Contributor

(Have been mostly just waiting for the discussion to settle before doing a proper review, and poking at random simple changes to the code where they don't require much thinking to verify they're correct.)

Comment thread library/core/src/alloc/mod.rs Outdated
Comment thread library/core/src/alloc/mod.rs Outdated
@@ -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
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