Rewrite safety requirements for `Allocator` impls by theemathas · Pull Request #157801 · rust-lang/rust

theemathas · 2026-06-12T10:27:27Z

This PR supersedes #156544.

I define the concept of "equivalent allocators", in order to be able to talk about cloning allocators, and to give commonsense guarantees about stdlib Allocator impls.

I define the concept of "invalidating a memory block" in order to be able to talk about users not being allowed to use a block of allocated memory after its allocator is "gone".

An Allocator implementation is now allowed to invalidate its allocations when the allocator is mutated or when a lifetime in the allocator type expires.

Mutation of an Allocator should sensibly be allowed to invalidate its allocations. For example, the bumpalo crates has a Bump::reset method that takes &mut self and invalidates all past allocations. Accesses via & still must not invalidate past allocations since, for example, Box provides & access to the allocator.

I still had the "allocator destructor" clause as a separate clause from the &mut clause, to avoid questions about whether drop glue of types that don't implement Drop but have fields that implement Drop counts as creating a &mut to the whole thing.

The "lifetime expiry" clause closes a hole/ambiguity on when an allocator is considered to be "dropped" if it does not have a destructor. Additionally, this clause matches what is required for Box::into_pin and {Rc, Arc}::pin to be sound. (Those methods have an A: 'static bound to prevent allocating via a &MyAllocator and then running MyAllocator's destructor.)

theemathas · 2026-06-12T10:40:19Z

+/// until that memory block is [*invalidated*]. The implementor must also
+/// not violate this invariant of `Allocator` via allocator equivalences
+/// that are in the implementor's control (e.g., via a misbehaving
+/// `impl Clone for Box<MyAllocator>`).


Any ideas on how to better word this?

View changes since the review

I define the concept of "equivalent allocators", in order to be able to talk about cloning allocators, and to give commonsense guarantees about stdlib `Allocator` impls. I define the concept of "invalidating a memory block" in order to be able to talk about users not being allowed to use a block of allocated memory after its allocator is "gone". An `Allocator` implementation is now allowed to invalidate its allocations when the allocator is mutated or when a lifetime in the allocator type expires. Mutation of an `Allocator` should sensibly be allowed to invalidate its allocations. For example, the `bumpalo` crates has a `Bump::reset` method that takes `&mut self` and invalidates all past allocations. Accesses via `&` still must not invalidate past allocations since, for example, `Box` provides `&` access to the allocator. I still had the "allocator destructor" clause as a separate clause from the `&mut` clause, to avoid questions about whether drop glue of types that don't implement `Drop` but have fields that implement `Drop` counts as creating a `&mut` to the whole thing. The "lifetime expiry" clause closes a hole/ambiguity on when an allocator is considered to be "dropped" if it does not have a destructor. Additionally, this clause matches what is required for `Box::into_pin` and `{Rc, Arc}::pin` to be sound. (Those methods have an `A: 'static` bound to prevent allocating via a `&MyAllocator` and then running `MyAllocator`'s destructor.)

theemathas · 2026-06-12T16:40:02Z

Talked in DMs with @nia-e, and we agreed that we should use a symmetric relationship, since that is easier to explain to users. If a library needs an asymmetric relationship, they can define their own concept with their own name, and that library can add that extra promise for their allocators on top of the requirements of Allocator.

theemathas · 2026-06-21T03:28:58Z

I'm going to nominate this, since the PR adds a wall of subtle and complicated text, and so probably needs multiple pairs of eyes on it.

Amanieu · 2026-07-07T16:10:41Z

@bors r+ rollup

rust-bors · 2026-07-07T16:10:44Z

📌 Commit d847075 has been approved by Amanieu

It is now in the queue for this repository.

@nia-e

…e, r=Amanieu Rewrite safety requirements for `Allocator` impls This PR supersedes rust-lang#156544. cc rust-lang#157428, rust-lang#156920 cc @nia-e r? @Amanieu (reviewer of rust-lang#156544) I define the concept of "equivalent allocators", in order to be able to talk about cloning allocators, and to give commonsense guarantees about stdlib `Allocator` impls. I define the concept of "invalidating a memory block" in order to be able to talk about users not being allowed to use a block of allocated memory after its allocator is "gone". An `Allocator` implementation is now allowed to invalidate its allocations when the allocator is mutated or when a lifetime in the allocator type expires. Mutation of an `Allocator` should sensibly be allowed to invalidate its allocations. For example, the `bumpalo` crates has a `Bump::reset` method that takes `&mut self` and invalidates all past allocations. Accesses via `&` still must not invalidate past allocations since, for example, `Box` provides `&` access to the allocator. I still had the "allocator destructor" clause as a separate clause from the `&mut` clause, to avoid questions about whether drop glue of types that don't implement `Drop` but have fields that implement `Drop` counts as creating a `&mut` to the whole thing. The "lifetime expiry" clause closes a hole/ambiguity on when an allocator is considered to be "dropped" if it does not have a destructor. Additionally, this clause matches what is required for `Box::into_pin` and `{Rc, Arc}::pin` to be sound. (Those methods have an `A: 'static` bound to prevent allocating via a `&MyAllocator` and then running `MyAllocator`'s destructor.)

@nia-e

…e, r=Amanieu Rewrite safety requirements for `Allocator` impls This PR supersedes rust-lang#156544. cc rust-lang#157428, rust-lang#156920 cc @nia-e r? @Amanieu (reviewer of rust-lang#156544) I define the concept of "equivalent allocators", in order to be able to talk about cloning allocators, and to give commonsense guarantees about stdlib `Allocator` impls. I define the concept of "invalidating a memory block" in order to be able to talk about users not being allowed to use a block of allocated memory after its allocator is "gone". An `Allocator` implementation is now allowed to invalidate its allocations when the allocator is mutated or when a lifetime in the allocator type expires. Mutation of an `Allocator` should sensibly be allowed to invalidate its allocations. For example, the `bumpalo` crates has a `Bump::reset` method that takes `&mut self` and invalidates all past allocations. Accesses via `&` still must not invalidate past allocations since, for example, `Box` provides `&` access to the allocator. I still had the "allocator destructor" clause as a separate clause from the `&mut` clause, to avoid questions about whether drop glue of types that don't implement `Drop` but have fields that implement `Drop` counts as creating a `&mut` to the whole thing. The "lifetime expiry" clause closes a hole/ambiguity on when an allocator is considered to be "dropped" if it does not have a destructor. Additionally, this clause matches what is required for `Box::into_pin` and `{Rc, Arc}::pin` to be sound. (Those methods have an `A: 'static` bound to prevent allocating via a `&MyAllocator` and then running `MyAllocator`'s destructor.)

…uwer Rollup of 18 pull requests Successful merges: - #157385 (Enable Enzyme on x86_64-apple) - #157561 (rustdoc: do not include extra stuff in span) - #158179 (std: unconditionally use `preadv`/`pwritev` on AArch64 macOS) - #158617 (allow mGCA const arguments to fall back to anon consts) - #158621 (disallow `extern "custom"` on wasm and spirv targets) - #158690 (delegation: support mapping of all arguments with `Self` type) - #158696 (Rename some `body_id` to `body_def_id`) - #158697 (Fixes for QNX SDP 8) - #158760 (Clarify that `LocalKey::try_with` may return `AccessError`) - #157801 (Rewrite safety requirements for `Allocator` impls) - #158333 (Fix typetree generation for differentiated functions) - #158646 (powerpc64le_unknown_freebsd.rs: link with -lgcc) - #158701 ( diagnostics: suggest type annotation for closure params on HRTB FnOnce mismatch) - #158791 (Avoid unused braces lint for macro generated arguments) - #158802 (Use `ci-mirrors` in `armhf-gnu` for {busybox, ubuntu rootfs} artifacts) - #158841 (Avoid final override ICE for RPITIT associated types) - #158889 (tests: catch up with LLVM returning f128 on the stack) - #158905 (delegation: add constraints to new generic args)

…uwer Rollup of 19 pull requests Successful merges: - #156016 (view-types: store view types in the AST) - #157385 (Enable Enzyme on x86_64-apple) - #158179 (std: unconditionally use `preadv`/`pwritev` on AArch64 macOS) - #158621 (disallow `extern "custom"` on wasm and spirv targets) - #158690 (delegation: support mapping of all arguments with `Self` type) - #158696 (Rename some `body_id` to `body_def_id`) - #158697 (Fixes for QNX SDP 8) - #158760 (Clarify that `LocalKey::try_with` may return `AccessError`) - #157801 (Rewrite safety requirements for `Allocator` impls) - #158085 (rustdoc: Fix sidebar heading order) - #158333 (Fix typetree generation for differentiated functions) - #158646 (powerpc64le_unknown_freebsd.rs: link with -lgcc) - #158701 ( diagnostics: suggest type annotation for closure params on HRTB FnOnce mismatch) - #158791 (Avoid unused braces lint for macro generated arguments) - #158802 (Use `ci-mirrors` in `armhf-gnu` for {busybox, ubuntu rootfs} artifacts) - #158841 (Avoid final override ICE for RPITIT associated types) - #158889 (tests: catch up with LLVM returning f128 on the stack) - #158905 (delegation: add constraints to new generic args) - #158922 (tests: clean up over-constraint on LLVM feature count) Failed merges: - #158617 (allow mGCA const arguments to fall back to anon consts)

@nia-e

Rollup merge of #157801 - theemathas:allocator-safety-rewrite, r=Amanieu Rewrite safety requirements for `Allocator` impls This PR supersedes #156544. cc #157428, #156920 cc @nia-e r? @Amanieu (reviewer of #156544) I define the concept of "equivalent allocators", in order to be able to talk about cloning allocators, and to give commonsense guarantees about stdlib `Allocator` impls. I define the concept of "invalidating a memory block" in order to be able to talk about users not being allowed to use a block of allocated memory after its allocator is "gone". An `Allocator` implementation is now allowed to invalidate its allocations when the allocator is mutated or when a lifetime in the allocator type expires. Mutation of an `Allocator` should sensibly be allowed to invalidate its allocations. For example, the `bumpalo` crates has a `Bump::reset` method that takes `&mut self` and invalidates all past allocations. Accesses via `&` still must not invalidate past allocations since, for example, `Box` provides `&` access to the allocator. I still had the "allocator destructor" clause as a separate clause from the `&mut` clause, to avoid questions about whether drop glue of types that don't implement `Drop` but have fields that implement `Drop` counts as creating a `&mut` to the whole thing. The "lifetime expiry" clause closes a hole/ambiguity on when an allocator is considered to be "dropped" if it does not have a destructor. Additionally, this clause matches what is required for `Box::into_pin` and `{Rc, Arc}::pin` to be sound. (Those methods have an `A: 'static` bound to prevent allocating via a `&MyAllocator` and then running `MyAllocator`'s destructor.)

rustbot assigned Amanieu Jun 12, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 12, 2026

theemathas mentioned this pull request Jun 12, 2026

Add more safety requirements for Allocator impls #156544

Closed

theemathas added A-allocators Area: Custom and system allocators T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 12, 2026

theemathas commented Jun 12, 2026

View reviewed changes

theemathas force-pushed the allocator-safety-rewrite branch from 2861839 to d9b90b0 Compare June 12, 2026 12:23

This comment was marked as resolved.

Sign in to view

nia-e reviewed Jun 12, 2026

View reviewed changes

This comment was marked as resolved.

Sign in to view

theemathas added needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. and removed needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. labels Jun 12, 2026

clarfonthey reviewed Jun 12, 2026

View reviewed changes

Comment thread library/core/src/alloc/mod.rs

Address feedback comments.

e9929d7

nia-e approved these changes Jun 15, 2026

View reviewed changes

theemathas added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Jun 21, 2026

clarfonthey mentioned this pull request Jun 29, 2026

allocator: refactor for stabilisation #157428

Open

theemathas commented Jun 30, 2026

View reviewed changes

Comment thread library/core/src/alloc/mod.rs Outdated

Fix conditions of & API invalidating memory blocks.

d847075

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 7, 2026

JonathanBrouwer mentioned this pull request Jul 7, 2026

Rollup of 7 pull requests #158919

Closed

JonathanBrouwer mentioned this pull request Jul 7, 2026

Rollup of 18 pull requests #158923

Closed

JonathanBrouwer mentioned this pull request Jul 7, 2026

Rollup of 19 pull requests #158924

Merged

rust-bors Bot merged commit d57f179 into rust-lang:main Jul 8, 2026
13 checks passed

rustbot added this to the 1.99.0 milestone Jul 8, 2026

theemathas deleted the allocator-safety-rewrite branch July 8, 2026 00:30

Uh oh!

Uh oh!

Conversation

theemathas commented Jun 12, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

theemathas Jun 12, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment was marked as resolved.

theemathas commented Jun 12, 2026

Uh oh!

Uh oh!

theemathas commented Jun 21, 2026

Uh oh!

Uh oh!

Amanieu commented Jul 7, 2026

Uh oh!

rust-bors Bot commented Jul 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

theemathas commented Jun 12, 2026 •

edited by rustbot

Loading

theemathas Jun 12, 2026 •

edited by rustbot

Loading