allocations are allowed to grow (but not shrink) by RalfJung · Pull Request #159729 · rust-lang/rust

RalfJung · 2026-07-22T16:35:02Z

This got permitted on the LLVM side about a year ago (llvm/llvm-project#141338), but didn't require any code changes since LLVM's optimizations were already compatible with growing allocations. That said, LLVM assumes that allocations created via operations it recognizes (e.g. malloc, alloca, or the Rust global allocator operations) never change their size, so we have to exclude that case.

This resolves a part of rust-lang/unsafe-code-guidelines#430.

It may seem strange that allocations can grow but not shrink, but we did have multiple users show up in #t-opsem with exactly that request. Cc @nhusung @foonathan; see here and here for some details about their use-cases.

Cc @rust-lang/opsem @rust-lang/lang

rustbot · 2026-07-22T16:35:08Z

r? @Darksonn

rustbot has assigned @Darksonn.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: libs
libs expanded to 12 candidates
Random selection from 6 candidates

RalfJung · 2026-07-22T16:35:42Z

@rfcbot merge opsem

rust-rfcbot · 2026-07-22T16:35:45Z

@RalfJung has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rust-rfcbot · 2026-07-22T19:16:53Z

🔔 This is now entering its final comment period, as per the review above. 🔔

Darksonn

@bors r+ rollup

View changes since this review

rust-bors · 2026-07-24T12:02:17Z

📋 This PR cannot be approved because it currently has the following label: final-comment-period.

rust-rfcbot · 2026-08-01T19:21:07Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

Darksonn · 2026-08-01T19:26:09Z

@bors r+ rollup

rust-bors · 2026-08-01T19:26:12Z

📌 Commit dcf4a3d has been approved by Darksonn

It is now in the queue for this repository.

@nhusung

allocations are allowed to grow (but not shrink) This got permitted on the LLVM side about a year ago (llvm/llvm-project#141338), but didn't require any code changes since LLVM's optimizations were already compatible with growing allocations. That said, LLVM assumes that allocations created via operations it recognizes (e.g. `malloc`, `alloca`, or the Rust global allocator operations) never change their size, so we have to exclude that case. This resolves a part of rust-lang/unsafe-code-guidelines#430. It may seem strange that allocations can grow but not shrink, but we did have multiple users show up in #t-opsem with exactly that request. Cc @nhusung @foonathan; see [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612181257) and [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612191402) for some details about their use-cases. Cc @rust-lang/opsem @rust-lang/lang

@nhusung

allocations are allowed to grow (but not shrink) This got permitted on the LLVM side about a year ago (llvm/llvm-project#141338), but didn't require any code changes since LLVM's optimizations were already compatible with growing allocations. That said, LLVM assumes that allocations created via operations it recognizes (e.g. `malloc`, `alloca`, or the Rust global allocator operations) never change their size, so we have to exclude that case. This resolves a part of rust-lang/unsafe-code-guidelines#430. It may seem strange that allocations can grow but not shrink, but we did have multiple users show up in #t-opsem with exactly that request. Cc @nhusung @foonathan; see [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612181257) and [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612191402) for some details about their use-cases. Cc @rust-lang/opsem @rust-lang/lang

Rollup of 6 pull requests Successful merges: - #159844 (Subtree cg_gcc sync (2026-07-24)) - #156527 (Move `std::io` tests to `alloctests` & add prelude) - #159525 (Stabilize passing 128-bit integers via vector registers with `asm!` on x86) - #160342 (Specialize `advance_by` method of `Fuse`) - #106643 (Allow only implementing `Read::read_buf`) - #159729 (allocations are allowed to grow (but not shrink))

@nhusung

allocations are allowed to grow (but not shrink) This got permitted on the LLVM side about a year ago (llvm/llvm-project#141338), but didn't require any code changes since LLVM's optimizations were already compatible with growing allocations. That said, LLVM assumes that allocations created via operations it recognizes (e.g. `malloc`, `alloca`, or the Rust global allocator operations) never change their size, so we have to exclude that case. This resolves a part of rust-lang/unsafe-code-guidelines#430. It may seem strange that allocations can grow but not shrink, but we did have multiple users show up in #t-opsem with exactly that request. Cc @nhusung @foonathan; see [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612181257) and [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612191402) for some details about their use-cases. Cc @rust-lang/opsem @rust-lang/lang

Rollup of 6 pull requests Successful merges: - #156527 (Move `std::io` tests to `alloctests` & add prelude) - #159525 (Stabilize passing 128-bit integers via vector registers with `asm!` on x86) - #160342 (Specialize `advance_by` method of `Fuse`) - #106643 (Allow only implementing `Read::read_buf`) - #159729 (allocations are allowed to grow (but not shrink)) - #159881 (fix: Do not stop `visible_parent_map` breadth-first search reaching children of `#[doc(hidden)]` modules)

@nhusung

allocations are allowed to grow (but not shrink) This got permitted on the LLVM side about a year ago (llvm/llvm-project#141338), but didn't require any code changes since LLVM's optimizations were already compatible with growing allocations. That said, LLVM assumes that allocations created via operations it recognizes (e.g. `malloc`, `alloca`, or the Rust global allocator operations) never change their size, so we have to exclude that case. This resolves a part of rust-lang/unsafe-code-guidelines#430. It may seem strange that allocations can grow but not shrink, but we did have multiple users show up in #t-opsem with exactly that request. Cc @nhusung @foonathan; see [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612181257) and [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612191402) for some details about their use-cases. Cc @rust-lang/opsem @rust-lang/lang

…uwer Rollup of 12 pull requests Successful merges: - #159906 (Semantic check of `mut` restrictions) - #156527 (Move `std::io` tests to `alloctests` & add prelude) - #159525 (Stabilize passing 128-bit integers via vector registers with `asm!` on x86) - #160342 (Specialize `advance_by` method of `Fuse`) - #160358 (borrowck: Simplify deps to build compiler 30s faster) - #160375 (miri subtree update) - #106643 (Allow only implementing `Read::read_buf`) - #159499 (tests: prefer max-llvm-major-version over open LLVM ranges) - #159729 (allocations are allowed to grow (but not shrink)) - #159881 (fix: Do not stop `visible_parent_map` breadth-first search reaching children of `#[doc(hidden)]` modules) - #160189 (Move codegen_stmt_debuginfo to debuginfo.rs) - #160356 (Add more tests for `must_implement_one_of`)

@nhusung

Rollup merge of #159729 - RalfJung:alloc-grow, r=Darksonn allocations are allowed to grow (but not shrink) This got permitted on the LLVM side about a year ago (llvm/llvm-project#141338), but didn't require any code changes since LLVM's optimizations were already compatible with growing allocations. That said, LLVM assumes that allocations created via operations it recognizes (e.g. `malloc`, `alloca`, or the Rust global allocator operations) never change their size, so we have to exclude that case. This resolves a part of rust-lang/unsafe-code-guidelines#430. It may seem strange that allocations can grow but not shrink, but we did have multiple users show up in #t-opsem with exactly that request. Cc @nhusung @foonathan; see [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612181257) and [here](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Shrinking.20allocations.20in-place/near/612191402) for some details about their use-cases. Cc @rust-lang/opsem @rust-lang/lang

…uwer Rollup of 12 pull requests Successful merges: - rust-lang/rust#159906 (Semantic check of `mut` restrictions) - rust-lang/rust#156527 (Move `std::io` tests to `alloctests` & add prelude) - rust-lang/rust#159525 (Stabilize passing 128-bit integers via vector registers with `asm!` on x86) - rust-lang/rust#160342 (Specialize `advance_by` method of `Fuse`) - rust-lang/rust#160358 (borrowck: Simplify deps to build compiler 30s faster) - rust-lang/rust#160375 (miri subtree update) - rust-lang/rust#106643 (Allow only implementing `Read::read_buf`) - rust-lang/rust#159499 (tests: prefer max-llvm-major-version over open LLVM ranges) - rust-lang/rust#159729 (allocations are allowed to grow (but not shrink)) - rust-lang/rust#159881 (fix: Do not stop `visible_parent_map` breadth-first search reaching children of `#[doc(hidden)]` modules) - rust-lang/rust#160189 (Move codegen_stmt_debuginfo to debuginfo.rs) - rust-lang/rust#160356 (Add more tests for `must_implement_one_of`)

rustbot assigned Darksonn Jul 22, 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 Jul 22, 2026

rust-rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jul 22, 2026

RalfJung mentioned this pull request Jul 22, 2026

Can allocations have gaps? Can they be partially deallocated? Can they grow "in-place"? rust-lang/unsafe-code-guidelines#430

Open

RalfJung changed the title ~~allocations are allowed to grow~~ allocations are allowed to grow (but not shrink) Jul 22, 2026

rust-rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Jul 22, 2026

rust-rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Jul 22, 2026

Mark-Simulacrum reviewed Jul 23, 2026

View reviewed changes

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

RalfJung force-pushed the alloc-grow branch 2 times, most recently from d8c3c0c to 122a5c6 Compare July 23, 2026 07:56

Darksonn reviewed Jul 23, 2026

View reviewed changes

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

allocations are allowed to grow

dcf4a3d

RalfJung force-pushed the alloc-grow branch from 122a5c6 to dcf4a3d Compare July 23, 2026 08:21

Darksonn approved these changes Jul 24, 2026

View reviewed changes

Darksonn added S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 25, 2026

rustbot mentioned this pull request Aug 1, 2026

Tracking issue for release notes of #159729: allocations are allowed to grow (but not shrink) #160353

Open

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 Aug 1, 2026

JonathanBrouwer mentioned this pull request Aug 1, 2026

Rollup of 3 pull requests #160357

Closed

jhpratt mentioned this pull request Aug 1, 2026

Rollup of 6 pull requests #160361

Closed

jhpratt mentioned this pull request Aug 2, 2026

Rollup of 6 pull requests #160367

Closed

This was referenced Aug 2, 2026

Rollup of 11 pull requests #160383

Closed

Rollup of 12 pull requests #160388

Merged

rust-bors Bot merged commit 032d9c6 into rust-lang:main Aug 2, 2026
13 checks passed

rustbot added this to the 1.99.0 milestone Aug 2, 2026

RalfJung deleted the alloc-grow branch August 3, 2026 08:55

Navigation Menu

Uh oh!

Uh oh!

allocations are allowed to grow (but not shrink) - #159729

allocations are allowed to grow (but not shrink)#159729
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
RalfJung:alloc-grow

RalfJung commented Jul 22, 2026 •

edited

Loading

Uh oh!

rustbot commented Jul 22, 2026

Uh oh!

RalfJung commented Jul 22, 2026

Uh oh!

rust-rfcbot commented Jul 22, 2026 •

edited by saethlin

Loading

Uh oh!

rust-rfcbot commented Jul 22, 2026

Uh oh!

Uh oh!

Uh oh!

Darksonn left a comment •

edited by rustbot

Loading

Uh oh!

rust-bors Bot commented Jul 24, 2026

Uh oh!

rust-rfcbot commented Aug 1, 2026

Uh oh!

Darksonn commented Aug 1, 2026

Uh oh!

rust-bors Bot commented Aug 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

RalfJung commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 22, 2026

Uh oh!

RalfJung commented Jul 22, 2026

Uh oh!

rust-rfcbot commented Jul 22, 2026 • edited by saethlin Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-rfcbot commented Jul 22, 2026

Uh oh!

Uh oh!

Uh oh!

Darksonn left a comment • 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!

rust-bors Bot commented Jul 24, 2026

Uh oh!

rust-rfcbot commented Aug 1, 2026

Uh oh!

Darksonn commented Aug 1, 2026

Uh oh!

rust-bors Bot commented Aug 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

RalfJung commented Jul 22, 2026 •

edited

Loading

rust-rfcbot commented Jul 22, 2026 •

edited by saethlin

Loading

Darksonn left a comment •

edited by rustbot

Loading