alloc: stabilise `Allocator` by nia-e · Pull Request #156882 · rust-lang/rust

nia-e · 2026-05-24T16:57:31Z

Stabilise a bare-minimum (dyn-incompatible, but could be in the future) Allocator trait, alongside Box::new_in(), Vec::new_in(), the System & Global Allocators, and a blanket impl of Allocator for T: GlobalAlloc. For now, we should take care not to make it possible to instantiate anything other than a Vec or Box with custom allocators; it's Probably Fine, but worth a proper look before we rush in.

The soundness requirements for implementors were tightened to the most restrictive ones we could reasonably want per a conversation with @RalfJung.

This was discussed extensively at the all-hands with an apparent tentative consensus from libs and participating ecosystem stakeholders that the current design can be extended backwards-compatibly to address almost all usecases.

cc @rust-lang/libs @rust-lang/libs-api @rust-lang/opsem

r? libs

Edit, following more points being discovered: see the new stabilisation report

nia-e · 2026-05-24T17:15:25Z

r? @Amanieu

theemathas · 2026-05-25T00:07:56Z

I believe the safety requirements are not yet correct. See #156544

nia-e · 2026-06-01T10:51:21Z

Given the feedback here & on Zulip, the new design for allocator_api probably needs some time to bake & iron out soundness bugs. I'll be keeping the previous document up-to-date w/ any changes or updates, but it likely makes sense to first land these changes unstably and then see if it holds up to scrutiny. I do think something could be stabilised soon-ish, but there won't be any harm in waiting a bit ^^

edit: the conversation will mainly continue on zulip and on the issues filed in response to this PR; if you have concerns not yet addressed, please ping me there and i'll happily look into seeing if the design can be adapted

@rustbot author

rust-bors · 2026-06-02T16:09:39Z

☔ The latest upstream changes (presumably #157303) made this pull request unmergeable. Please resolve the merge conflicts.

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

@nia-e

allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097a8e36f9f3256f6a7972e2da8f1f2ca6d5 (rust-lang/rust#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated

rustbot assigned Mark-Simulacrum May 24, 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 May 24, 2026

nia-e added A-allocators Area: Custom and system allocators relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. labels May 24, 2026

rustbot mentioned this pull request May 24, 2026

Tracking issue for release notes of #156882: alloc: stabilise Allocator #156883

Open

nia-e added needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. and removed S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. labels May 24, 2026

rustbot assigned Amanieu and unassigned Mark-Simulacrum May 24, 2026

This comment has been minimized.

Sign in to view

CAD97 reviewed May 24, 2026

View reviewed changes

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

nia-e force-pushed the stable-allocator branch from ecf76bf to ed24b36 Compare May 24, 2026 17:42

programmerjake reviewed May 24, 2026

View reviewed changes

Comment thread library/alloc/src/collections/binary_heap/mod.rs Outdated

fmease reviewed May 24, 2026

View reviewed changes

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

coolreader18 reviewed May 24, 2026

View reviewed changes

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

bushrat011899 reviewed May 24, 2026

View reviewed changes

Comment thread tests/ui/allocator/not-an-allocator.u.stderr Outdated

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

clarfonthey mentioned this pull request May 24, 2026

Update allocator-api2 rust-lang/hashbrown#672

Open

SimonSapin reviewed May 24, 2026

View reviewed changes

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

This comment has been minimized.

Sign in to view

This comment was marked as outdated.

Sign in to view

nia-e removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Jun 1, 2026

nia-e marked this pull request as draft June 1, 2026 10:51

This comment was marked as off-topic.

Sign in to view

jmillikin mentioned this pull request Jun 2, 2026

Stabilize dyn subset of Allocator as core::alloc::Alloc #157286

Closed

197g mentioned this pull request Jun 2, 2026

PNG: Account for memory limit when decompressing text image-rs/image#3009

Merged

nia-e mentioned this pull request Jun 4, 2026

allocator: refactor for stabilisation #157428

Open

cetra3 mentioned this pull request Jun 11, 2026

[EPIC] A collection of Memory Accounting Limitations and Improvements apache/datafusion#22758

Open

9 tasks

This comment was marked as off-topic.

Sign in to view

maxdexh mentioned this pull request Jul 22, 2026

document #[global_allocator] constraints #159720

Open

Uh oh!

Uh oh!

Conversation

nia-e commented May 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nia-e commented May 24, 2026

Uh oh!

This comment has been minimized.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

theemathas commented May 25, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment was marked as outdated.

This comment was marked as outdated.

nia-e commented Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as off-topic.

This comment was marked as off-topic.

rust-bors Bot commented Jun 2, 2026

Uh oh!

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

nia-e commented May 24, 2026 •

edited

Loading

nia-e commented Jun 1, 2026 •

edited

Loading