make closures act like MaybeDangling by RalfJung · Pull Request #160745 · rust-lang/rust

RalfJung · 2026-08-08T11:12:25Z

This makes closures (and types like them: coroutines and coroutine closures) act like MaybeDangling. This means that the aliasing model will entirely ignore references and Boxes passed around as closure captures, removing a pretty subtle footgun that has already caused multiple soundness issues:

The standard library thread spawning logic was unsound because it passed around arbitrary user data in a closure capture. See Scoped threads violate 'dereferenceable for function call' requirement of references #101983 for details. I doubt that this is the only such unsoundness in the ecosystem, this is just very hard to find -- you need to not only run your code in Miri but also pass very specific types through your API to trigger the UB.
Movable (unpinned) generators can contain mutable references that are reborrowed from other references stored in the same generator. This is currently unsound. The only way this is sound is if the reborrowed-from references are inside MaybeDangling; without this, moving the generator (which retags its contents) invalidates the reborrowed reference. So at least for generators, we have to do this change anyway one way or another.

Here's an example of code that no longer has UB under this PR:

fn invoke(f: impl FnOnce()) {
    f()
}

fn main() {
    let p = Box::leak(Box::new(0i32));
    invoke(move || {
        drop(unsafe { Box::from_raw(p) });
    });
}

Basically, what we are establishing here is that immediately invoking a closure should be (almost) equivalent to just inlining its body. (There is still a caveat here in that if you capture things that violate their validity invariant, the inlined body might not care but immediately invoking the closure will. But at least for all the subtle questions around aliasing, the two will be equivalent under this PR.)

Overall I think the fact that moving a closure / generator will alter its contents (by retagging) is just a bit too subtle. It's already subtle for "normal" types but there at least one can see the type with its fields. For closures, that's all entirely implicit. At the same time, the benefit we get from this at the moment is tiny -- we can only actually tell LLVM about these references if the closure/generator has scalar / scalar-pair representation, which can only happen when it captures at most 2 scalar values.

This PR just implements the semantics without updating any docs. I am not sure where we'd document this, given our general lack of documentation around the aliasing model. Still we should t-opsem FCP this PR to ensure we have team consensus for not retagging or requiring reference dereferenceability inside closoures and closure-like types (and then we can involve lang if/when we start making official promises about this).

On the implementation side, I realized this by introducing the notion of "maybe-dangling-like" types, so that the semantics is not hard-coded specifically to MaybeDangling. This also lets us simplify ManuallyDrop, reducing its field nesting a bit, which should help with some of the query limit issues people encountered when we added the extra field nesting. It also means generators get the desired semantics without increasing their field nesting. Cc @WaffleLapkin

Fixes #159443

rustbot · 2026-08-08T11:12:28Z

miri is developed in its own repository. If the Miri part of this change can be broken out, consider making this change to rust-lang/miri instead. However, if Miri needs adjusting for rustc changes, just ignore this message.

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

rustbot · 2026-08-08T11:12:31Z

r? @clarfonthey

rustbot has assigned @clarfonthey.
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 JohnTitor, Mark-Simulacrum, clarfonthey, nia-e

RalfJung · 2026-08-08T11:14:54Z

@rfcbot merge opsem

rust-rfcbot · 2026-08-08T11:14:56Z

@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.

clarfonthey · 2026-08-08T15:04:17Z

r? compiler

This isn't really a libs change.

CAD97 · 2026-08-08T18:13:32Z

@rustbot reviewed

The unpin generators case could theoretically be solved by making generators specifically !UnsafeUnpin. Even if fix the opsem by giving all closures MaybeDangling semantics, this could arguably still be a correct (removal of) application of the autotrait.

FnOnce closures can't be used after they're consumed, so the "morally correct" fix is that usage sites that could logically move from impl FnOnce should be wrapping it in ManuallyDrop so the compiler can know that this is happening.

But in the face of std getting it wrong¹, and of unpin generators hitting another very subtle case of not being logically pinned but still needing to be (logically) wrapped in UnsafePinned, I agree that giving all closures (fixed) ManuallyDrop (i.e. MaybeDangling) semantics

Furthermore, I strongly suspect that giving closures MaybeDangling semantics won't have an observable impact on performance. (Though this assumption should be tested.) Namely, because uses of closures will either be monomorphic and able to re-infer the stronger properties that hold; or polymorphic, need to be conservative, and the opportunity cost largely dominated by the indirect call anyway.

And notably, IIRC, the version that got it wrong and was fixed with MaybeUninit didn't use ManuallyDrop despite it being stable, which is intended to have semantics that would also fix the soundness pitfall. (Although it didn't yet at the time.) ↩

CAD97 · 2026-08-08T18:30:54Z

I almost forgot the strongest rationale: there's the really subtle case where you might think you're capturing a pointer but actually capture a (potentially mutable) reference instead because of how place capture rules work.

fn invoke(f: impl FnOnce()) {
    f()
}

fn main() {
    let p = Box::leak(Box::new(0i32));
    invoke(|| {
        drop(unsafe { Box::from_raw(&raw mut *p) });
    });
}

Note: I could've sworn that having ptr: *mut i32 and using it as &mut *ptr would capture *ptr by-mut instead of capturing ptr by-move. That footgun was extremely dangerous, so I'm glad we fixed it already and I just forgot that we did.

The remaining instance of this style of footgun is much less potent than the one I recall existing previously, but combined with the other evidence that retagging closures' captures when retagging the impl FnOnce is fraught with subtle footguns that the most experienced Rust programmers did miss originally, the practical decision is to merge this change.

RalfJung · 2026-08-08T20:00:42Z

The unpin generators case could theoretically be solved by making generators specifically !UnsafeUnpin.

That would not help. The problem is the retag that happens when we move the generator. At that point it is not behind any kind of reference so no amount of UnsafeCell/UnsafeUnpin makes a difference.

Furthermore, I strongly suspect that giving closures MaybeDangling semantics won't have an observable impact on performance.

The example in the OP actually does get noalias currently which we'd lose.
But I doubt that's a common enough pattern to matter.

nnethercote · 2026-08-09T09:13:50Z

I am not a good reviewer for this. Gonna guess a better one, please reassign if this is a bad choice:

r? @saethlin

rust-rfcbot · 2026-08-19T16:32:48Z

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.

RalfJung · 2026-08-19T16:53:13Z

@rustbot ready

RalfJung · 2026-09-02T22:21:18Z

@WaffleLapkin friendly review ping. :)

WaffleLapkin

I don't have an opinion on the semantic change, but I think it is implemented correctly. r=me with or without the nit.

View changes since this review

WaffleLapkin · 2026-09-04T13:27:55Z

                    }
                }

+                // Patch result if we are a MaybeDangling-like type.


I don't really like this patching, but I don't see an easy way to make this better, so it's fine for now.

FWIW this is pre-existing, I am just being more explicit in the comments.

rustbot · 2026-09-04T14:30:54Z

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.

RalfJung · 2026-09-04T14:40:53Z

@bors r=WaffleLapkin

rust-bors · 2026-09-04T14:40:56Z

📋 This PR cannot be approved because it currently has the following label: needs-fcp.

RalfJung · 2026-09-04T14:41:10Z

@bors r=WaffleLapkin

rust-bors · 2026-09-04T14:41:12Z

📌 Commit 60b5f88 has been approved by WaffleLapkin

It is now in the queue for this repository.

@WaffleLapkin

…=WaffleLapkin make closures act like MaybeDangling This makes closures (and types like them: coroutines and coroutine closures) act like MaybeDangling. This means that the aliasing model will entirely ignore references and `Box`es passed around as closure captures, removing a pretty subtle footgun that has already caused multiple soundness issues: - The standard library thread spawning logic was unsound because it passed around arbitrary user data in a closure capture. See rust-lang#101983 for details. I doubt that this is the only such unsoundness in the ecosystem, this is just very hard to find -- you need to not only run your code in Miri but also pass very specific types through your API to trigger the UB. - Movable (unpinned) generators can contain mutable references that are reborrowed from other references stored in the same generator. This is currently [unsound](rust-lang#159443). The only way this is sound is if the reborrowed-from references are inside MaybeDangling; without this, moving the generator (which retags its contents) invalidates the reborrowed reference. So at least for generators, we have to do this change anyway one way or another. Here's an example of code that no longer has UB under this PR: ```rust fn invoke(f: impl FnOnce()) { f() } fn main() { let p = Box::leak(Box::new(0i32)); invoke(move || { drop(unsafe { Box::from_raw(p) }); }); } ``` Basically, what we are establishing here is that immediately invoking a closure should be (almost) equivalent to just inlining its body. (There is still a caveat here in that if you capture things that violate their validity invariant, the inlined body might not care but immediately invoking the closure will. But at least for all the subtle questions around aliasing, the two will be equivalent under this PR.) Overall I think the fact that moving a closure / generator will alter its contents (by retagging) is just a bit too subtle. It's already subtle for "normal" types but there at least one can see the type with its fields. For closures, that's all entirely implicit. At the same time, the benefit we get from this at the moment is tiny -- we can only actually tell LLVM about these references if the closure/generator has scalar / scalar-pair representation, which can only happen when it captures at most 2 scalar values. This PR just implements the semantics without updating any docs. I am not sure where we'd document this, given our general lack of documentation around the aliasing model. Still we should t-opsem FCP this PR to ensure we have team consensus for not retagging or requiring reference dereferenceability inside closoures and closure-like types (and then we can involve lang if/when we start making official promises about this). On the implementation side, I realized this by introducing the notion of "maybe-dangling-like" types, so that the semantics is not hard-coded specifically to `MaybeDangling`. This also lets us simplify `ManuallyDrop`, reducing its field nesting a bit, which should help with some of the query limit issues people encountered when we added the extra field nesting. It also means generators get the desired semantics without increasing their field nesting. Cc @WaffleLapkin Fixes rust-lang#159443

Rollup of 25 pull requests Successful merges: - #159074 ([PAC] FnAbi, llvm.ptrauth.resign and Session API change (2/8)) - #159792 (A more readable debug map for IndexMaps) - #160745 (make closures act like MaybeDangling) - #161895 (std::sys::pal::sgx: fix mismatched alloc/free alignment) - #161940 (Promote `wasm32-wasip3` to a tier 2 target) - #162072 (Add new Tier-3 target: `powerpc64-sony-ps3`) - #162179 (type system const items via direct rhs) - #162277 (Introduce `rustc_middle::middel::resolve`) - #162285 (box: fixup map/try_map deallocate calls) - #162286 (string: don't unwind prematurely) - #162289 (alloc: a bunch of safety comments) - #162292 (Update `askama` version to `0.16.1`) - #160509 (Remove `RegionExt`; move methods to `Region` in `rustc_type_ir`) - #160906 (Suggest usize instead of placeholder type for array length constants) - #160936 (traits: Represent live alias arguments as bitsets) - #161400 (Improve diagnostics for references to closures) - #161656 (Suggest mutable references for FnMut closure arguments) - #161711 (Add more splat fn type tests) - #161786 (Make `tcx.def_id_partial_cmp` public) - #161953 (sanitizers: Implicitly disable mutually exclusive sanitizers) - #162155 (add suggestion for `rustc_allowed_through_unstable_modules` attribute) - #162212 (Implement `Rng` for `Box`) - #162246 (Fix incorrect meta span) - #162266 (std: fix typo) - #162291 (Add regression test from 1.98.1)

@WaffleLapkin

…=WaffleLapkin make closures act like MaybeDangling This makes closures (and types like them: coroutines and coroutine closures) act like MaybeDangling. This means that the aliasing model will entirely ignore references and `Box`es passed around as closure captures, removing a pretty subtle footgun that has already caused multiple soundness issues: - The standard library thread spawning logic was unsound because it passed around arbitrary user data in a closure capture. See rust-lang#101983 for details. I doubt that this is the only such unsoundness in the ecosystem, this is just very hard to find -- you need to not only run your code in Miri but also pass very specific types through your API to trigger the UB. - Movable (unpinned) generators can contain mutable references that are reborrowed from other references stored in the same generator. This is currently [unsound](rust-lang#159443). The only way this is sound is if the reborrowed-from references are inside MaybeDangling; without this, moving the generator (which retags its contents) invalidates the reborrowed reference. So at least for generators, we have to do this change anyway one way or another. Here's an example of code that no longer has UB under this PR: ```rust fn invoke(f: impl FnOnce()) { f() } fn main() { let p = Box::leak(Box::new(0i32)); invoke(move || { drop(unsafe { Box::from_raw(p) }); }); } ``` Basically, what we are establishing here is that immediately invoking a closure should be (almost) equivalent to just inlining its body. (There is still a caveat here in that if you capture things that violate their validity invariant, the inlined body might not care but immediately invoking the closure will. But at least for all the subtle questions around aliasing, the two will be equivalent under this PR.) Overall I think the fact that moving a closure / generator will alter its contents (by retagging) is just a bit too subtle. It's already subtle for "normal" types but there at least one can see the type with its fields. For closures, that's all entirely implicit. At the same time, the benefit we get from this at the moment is tiny -- we can only actually tell LLVM about these references if the closure/generator has scalar / scalar-pair representation, which can only happen when it captures at most 2 scalar values. This PR just implements the semantics without updating any docs. I am not sure where we'd document this, given our general lack of documentation around the aliasing model. Still we should t-opsem FCP this PR to ensure we have team consensus for not retagging or requiring reference dereferenceability inside closoures and closure-like types (and then we can involve lang if/when we start making official promises about this). On the implementation side, I realized this by introducing the notion of "maybe-dangling-like" types, so that the semantics is not hard-coded specifically to `MaybeDangling`. This also lets us simplify `ManuallyDrop`, reducing its field nesting a bit, which should help with some of the query limit issues people encountered when we added the extra field nesting. It also means generators get the desired semantics without increasing their field nesting. Cc @WaffleLapkin Fixes rust-lang#159443

@WaffleLapkin

…=WaffleLapkin make closures act like MaybeDangling This makes closures (and types like them: coroutines and coroutine closures) act like MaybeDangling. This means that the aliasing model will entirely ignore references and `Box`es passed around as closure captures, removing a pretty subtle footgun that has already caused multiple soundness issues: - The standard library thread spawning logic was unsound because it passed around arbitrary user data in a closure capture. See rust-lang#101983 for details. I doubt that this is the only such unsoundness in the ecosystem, this is just very hard to find -- you need to not only run your code in Miri but also pass very specific types through your API to trigger the UB. - Movable (unpinned) generators can contain mutable references that are reborrowed from other references stored in the same generator. This is currently [unsound](rust-lang#159443). The only way this is sound is if the reborrowed-from references are inside MaybeDangling; without this, moving the generator (which retags its contents) invalidates the reborrowed reference. So at least for generators, we have to do this change anyway one way or another. Here's an example of code that no longer has UB under this PR: ```rust fn invoke(f: impl FnOnce()) { f() } fn main() { let p = Box::leak(Box::new(0i32)); invoke(move || { drop(unsafe { Box::from_raw(p) }); }); } ``` Basically, what we are establishing here is that immediately invoking a closure should be (almost) equivalent to just inlining its body. (There is still a caveat here in that if you capture things that violate their validity invariant, the inlined body might not care but immediately invoking the closure will. But at least for all the subtle questions around aliasing, the two will be equivalent under this PR.) Overall I think the fact that moving a closure / generator will alter its contents (by retagging) is just a bit too subtle. It's already subtle for "normal" types but there at least one can see the type with its fields. For closures, that's all entirely implicit. At the same time, the benefit we get from this at the moment is tiny -- we can only actually tell LLVM about these references if the closure/generator has scalar / scalar-pair representation, which can only happen when it captures at most 2 scalar values. This PR just implements the semantics without updating any docs. I am not sure where we'd document this, given our general lack of documentation around the aliasing model. Still we should t-opsem FCP this PR to ensure we have team consensus for not retagging or requiring reference dereferenceability inside closoures and closure-like types (and then we can involve lang if/when we start making official promises about this). On the implementation side, I realized this by introducing the notion of "maybe-dangling-like" types, so that the semantics is not hard-coded specifically to `MaybeDangling`. This also lets us simplify `ManuallyDrop`, reducing its field nesting a bit, which should help with some of the query limit issues people encountered when we added the extra field nesting. It also means generators get the desired semantics without increasing their field nesting. Cc @WaffleLapkin Fixes rust-lang#159443

Rollup of 27 pull requests Successful merges: - #159074 ([PAC] FnAbi, llvm.ptrauth.resign and Session API change (2/8)) - #159792 (A more readable debug map for IndexMaps) - #160745 (make closures act like MaybeDangling) - #161940 (Promote `wasm32-wasip3` to a tier 2 target) - #162030 (Prevent `--test` to be used in `rustdoc-html` testsuite) - #162072 (Add new Tier-3 target: `powerpc64-sony-ps3`) - #162179 (type system const items via direct rhs) - #162262 (Avoid manually instantiating some binders in error reporting with `-Znext-solver`) - #162277 (Introduce `rustc_middle::middel::resolve`) - #162285 (box: fixup map/try_map deallocate calls) - #162286 (string: don't unwind prematurely) - #162289 (alloc: a bunch of safety comments) - #162290 (abby test DSL: AliasTyOutlivesViaEnv) - #162292 (Update `askama` version to `0.16.1`) - #160509 (Remove `RegionExt`; move methods to `Region` in `rustc_type_ir`) - #160906 (Suggest usize instead of placeholder type for array length constants) - #160936 (traits: Represent live alias arguments as bitsets) - #161400 (Improve diagnostics for references to closures) - #161656 (Suggest mutable references for FnMut closure arguments) - #161711 (Add more splat fn type tests) - #161786 (Make `tcx.def_id_partial_cmp` public) - #161953 (sanitizers: Implicitly disable mutually exclusive sanitizers) - #162155 (add suggestion for `rustc_allowed_through_unstable_modules` attribute) - #162212 (Implement `Rng` for `Box`) - #162246 (Fix incorrect meta span) - #162266 (std: fix typo) - #162291 (Add regression test from 1.98.1)

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

rustbot assigned clarfonthey Aug 8, 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 Aug 8, 2026

RalfJung added the T-opsem Relevant to the opsem team label Aug 8, 2026

This comment has been minimized.

Sign in to view

RalfJung force-pushed the closure-maybe-dangling branch from 75383ed to 932a86d Compare August 8, 2026 11:56

This comment has been minimized.

Sign in to view

RalfJung force-pushed the closure-maybe-dangling branch from 932a86d to a13be5a Compare August 8, 2026 12:55

This comment has been minimized.

Sign in to view

RalfJung force-pushed the closure-maybe-dangling branch 2 times, most recently from e3c49f3 to d919fe5 Compare August 8, 2026 15:00

rustbot assigned nnethercote and unassigned clarfonthey Aug 8, 2026

RalfJung added the needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. label Aug 8, 2026

rustbot assigned saethlin and unassigned nnethercote Aug 9, 2026

rust-rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Aug 9, 2026

rust-rfcbot removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. labels Aug 19, 2026

rust-rfcbot added the to-announce Announce this issue on triage meeting label Aug 19, 2026

rustbot mentioned this pull request Aug 19, 2026

Tracking issue for release notes of #160745: make closures act like MaybeDangling #161363

Closed

WaffleLapkin approved these changes Sep 4, 2026

View reviewed changes

RalfJung force-pushed the closure-maybe-dangling branch from 903b6d3 to b74e09e Compare September 4, 2026 14:30

RalfJung added 4 commits September 4, 2026 16:35

make closure-like types act like MaybeDangling

e7c3734

simplify ManuallyDrop by making it natively 'like MaybeDangling'

b7e5447

remove no-longer-needed MaybeDangling from thread spawning

95d43bf

add another movable-generator regression test

60b5f88

RalfJung force-pushed the closure-maybe-dangling branch from b74e09e to 60b5f88 Compare September 4, 2026 14:35

RalfJung removed the needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. label Sep 4, 2026

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 Sep 4, 2026

GuillaumeGomez mentioned this pull request Sep 4, 2026

Rollup of 25 pull requests #162300

Closed

GuillaumeGomez mentioned this pull request Sep 4, 2026

Rollup of 28 pull requests #162307

Closed

GuillaumeGomez mentioned this pull request Sep 4, 2026

Rollup of 27 pull requests #162308

Open

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Uh oh!

rustbot commented Aug 8, 2026

Uh oh!

rustbot commented Aug 8, 2026

Uh oh!

RalfJung commented Aug 8, 2026

Uh oh!

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

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

clarfonthey commented Aug 8, 2026

Uh oh!

CAD97 commented Aug 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

CAD97 commented Aug 8, 2026

Uh oh!

RalfJung commented Aug 8, 2026

Uh oh!

nnethercote commented Aug 9, 2026

Uh oh!

rust-rfcbot commented Aug 19, 2026

Uh oh!

RalfJung commented Aug 19, 2026

Uh oh!

RalfJung commented Sep 2, 2026

Uh oh!

WaffleLapkin 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!

Uh oh!

WaffleLapkin Sep 4, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Sep 4, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Sep 4, 2026

Uh oh!

RalfJung commented Sep 4, 2026

Uh oh!

rust-bors Bot commented Sep 4, 2026

Uh oh!

RalfJung commented Sep 4, 2026

Uh oh!

rust-bors Bot commented Sep 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

RalfJung commented Aug 8, 2026 •

edited

Loading

rust-rfcbot commented Aug 8, 2026 •

edited by saethlin

Loading

CAD97 commented Aug 8, 2026 •

edited

Loading

WaffleLapkin left a comment •

edited by rustbot

Loading