Make `pin!()` more foolproof. by theemathas · Pull Request #158061 · rust-lang/rust

theemathas · 2026-06-18T04:30:01Z

Previously, the soundness argument for the pin!() macro relied on very complicated conditions on what coercions are possible. As a result, it was not obvious whether the macro was sound or not, and the macro was potentially fragile to changes in how coercions work.

Therefore, we change the pin!() macro so that it relies on less subtle properties of coercions. In particular:

The soundness argument now only relies on enumerating the possible types that a coercion could produce, as opposed to relying on details about how coercion expectations are propagated.
The soundness argument now only requires reasoning about possible coercions between a single pair of types defined in the standard library, as opposed to reasoning about two pairs of types, with some involved types being defined by the user.

Fixes #153438. This PR supersedes the proposed FCP on that issue.

cc @dianne

r? types

lcnr

sgtm

i consider this to properly fix #153438. I don't worry about us adding random coercions inside of user defined types causing problems here, as that should also cause problems for abstractions outside of stdlib

View changes since this review

theemathas · 2026-07-01T13:47:31Z

This should hopefully be ready to merge now. @lcnr

mejrs

I've messed around with this some more and discovered that you can do this (no need for the custom error reporting code)

pub struct PinMacroHelper<T> {
    pub value: T,
}

impl<T> PinMacroHelper<T> {
    pub const unsafe fn pin_new_unchecked<'a>(&'a mut self) -> Pin<&'a mut T> {
        // SAFETY: Ensured by the caller.
        unsafe { Pin::new_unchecked(&mut self.value) }
    }
}

and then you get the error:

error[E0308]: mismatched types
  --> $DIR/dont-deref-coerce-pinned-value.rs:9:14
   |
LL | fn wrong_pin<T>(data: &mut T, callback: impl FnOnce(Pin<&mut T>)) {
   |              - expected this type parameter
LL |     callback(pin!(data));
   |              ^^^^^^^^^^ expected `Pin<&mut T>`, found `Pin<&mut &mut T>`
   |
   = note: expected struct `Pin<&mut _>`
              found struct `Pin<&mut &mut _>`

error: aborting due to 1 previous error

Anyway while I was messing around I noticed that the test passed while the error message changed. Can you add an explicit HELP/NOTE annotation so it doesn't regress?

View changes since this review

theemathas · 2026-07-06T04:08:18Z

@mejrs I avoided using the method call syntax because I didn't want to deal with autoref/autoderef. Do you think it's worth slightly complicating the soundness reasoning for the sake of diagnostics?

mejrs · 2026-07-06T10:07:28Z

@mejrs I avoided using the method call syntax because I didn't want to deal with autoref/autoderef. Do you think it's worth slightly complicating the soundness reasoning for the sake of diagnostics?

It would be nice to not have to put these hacks in the error reporting code... 🤔

Previously, the soundness argument for the `pin!()` macro relied on very complicated conditions on what coercions are possible. As a result, it was not obvious whether the macro was sound or not, and the macro was potentially fragile to changes in how coercions work. Therefore, we change the `pin!()` macro so that it relies on less subtle properties of coercions. In particular: * The soundness argument now only relies on enumerating the possible types that a coercion could produce, as opposed to relying on details about how coercion expectations are propagated. * The soundness argument now only requires reasoning about possible coercions between a single pair of types defined in the standard library, as opposed to reasoning about two pairs of types, with some involved types being defined by the user. Fixes <rust-lang#153438>

lcnr · 2026-07-13T10:42:24Z

Do you think it's worth slightly complicating the soundness reasoning for the sake of diagnostics?

is your concern that resolving method calls might have unintended behavior (e.g. preferring a trait method in scope or sth)

I do prefer not using method call syntax here I think. The diagnostics hack is somewhat ugly, but fine imo

lcnr · 2026-07-20T14:32:46Z

@bors r+ rollup

rust-bors · 2026-07-20T14:32:49Z

📌 Commit f0c86f6 has been approved by lcnr

It is now in the queue for this repository.

…uwer Rollup of 18 pull requests Successful merges: - #159600 (`rust-analyzer` subtree update) - #158046 (proc_macro: preserve file module spans for inner attrs) - #159000 (Small cleanups to the incr comp session code) - #159189 (Account for type alias projections in E0308 "expected/found" shortening logic) - #159449 (Enable single Location to issue multiple borrows) - #159544 (Suggest valid command-line crate names) - #159587 (Improve `AttrItem::span`) - #159594 (feat(rustc_hir_typeck): suggest `impl Fn` return for capturing closures) - #159597 (std: use `arc4random_buf` from libc) - #159599 (Resolver: Record at least 1 ambiguous trait if main decl is not a trait.) - #158061 (Make `pin!()` more foolproof.) - #159460 (Do not mark unnormalized const aliases as rigid when normalizing param env) - #159529 (Add regression test for nested replacement ranges in `collect_tokens`) - #159571 (Remove unused bundled library lookup for the local crate) - #159585 (Minor `TokenStream` improvements) - #159586 (Separate `InterpCx` usage by `ConstAnalysis` phases) - #159602 (Remove `ItemLike`) - #159603 (Clarify `push_stream`/`push_tree`) Failed merges: - #159590 (Remove some dead code)

@dianne

Rollup merge of #158061 - theemathas:pin-foolproof, r=lcnr Make `pin!()` more foolproof. Previously, the soundness argument for the `pin!()` macro relied on very complicated conditions on what coercions are possible. As a result, it was not obvious whether the macro was sound or not, and the macro was potentially fragile to changes in how coercions work. Therefore, we change the `pin!()` macro so that it relies on less subtle properties of coercions. In particular: * The soundness argument now only relies on enumerating the possible types that a coercion could produce, as opposed to relying on details about how coercion expectations are propagated. * The soundness argument now only requires reasoning about possible coercions between a single pair of types defined in the standard library, as opposed to reasoning about two pairs of types, with some involved types being defined by the user. Fixes <#153438>. This PR supersedes the proposed FCP on that issue. cc @dianne r? types

theemathas added T-libs Relevant to the library team, which will review and decide on the PR/issue. A-pin Area: Pin T-types Relevant to the types team, which will review and decide on the PR/issue. labels Jun 18, 2026

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 18, 2026

rustbot assigned lcnr Jun 18, 2026

theemathas mentioned this pull request Jun 18, 2026

pin!() is unsound due to coercions #153438

Closed

Darksonn reviewed Jun 18, 2026

View reviewed changes

Comment thread tests/ui/pin/dont-deref-coerce-pinned-value.stderr

lcnr reviewed Jun 29, 2026

View reviewed changes

Comment thread library/core/src/pin.rs Outdated

Comment thread tests/ui/pin/dont-deref-coerce-pinned-value.stderr

theemathas force-pushed the pin-foolproof branch from 3f561c7 to 609617c Compare June 29, 2026 13:49

mejrs reviewed Jun 30, 2026

View reviewed changes

Comment thread library/core/src/pin.rs Outdated

Comment thread tests/ui/pin/dont-deref-coerce-pinned-value.stderr

theemathas 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 Jul 1, 2026

theemathas force-pushed the pin-foolproof branch from 609617c to f9a03b6 Compare July 1, 2026 12:43

theemathas added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 1, 2026

Fayti1703 reviewed Jul 2, 2026

View reviewed changes

Comment thread compiler/rustc_trait_selection/src/error_reporting/infer/mod.rs Outdated

theemathas force-pushed the pin-foolproof branch from 859cf1c to bcc6b8a Compare July 2, 2026 14:51

mejrs reviewed Jul 5, 2026

View reviewed changes

Darksonn reviewed Jul 6, 2026

View reviewed changes

Comment thread library/core/src/pin.rs

theemathas force-pushed the pin-foolproof branch from bcc6b8a to c1f7194 Compare July 6, 2026 13:13

lcnr reviewed Jul 13, 2026

View reviewed changes

Comment thread compiler/rustc_trait_selection/src/error_reporting/infer/mod.rs Outdated

theemathas 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 Jul 13, 2026

Improve diagnostics for pin!() with wrong type.

f0c86f6

theemathas force-pushed the pin-foolproof branch from c1f7194 to f0c86f6 Compare July 13, 2026 13:17

theemathas added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 13, 2026

This comment was marked as resolved.

Sign in to view

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 20, 2026

JonathanBrouwer mentioned this pull request Jul 20, 2026

Rollup of 18 pull requests #159610

Merged

rust-bors Bot merged commit 509ed74 into rust-lang:main Jul 20, 2026
15 of 16 checks passed

theemathas deleted the pin-foolproof branch July 20, 2026 23:58

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

theemathas commented Jul 1, 2026

Uh oh!

Uh oh!

mejrs left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

theemathas commented Jul 6, 2026

Uh oh!

Uh oh!

mejrs commented Jul 6, 2026

Uh oh!

Uh oh!

lcnr commented Jul 13, 2026

Uh oh!

This comment was marked as resolved.

lcnr commented Jul 20, 2026

Uh oh!

rust-bors Bot commented Jul 20, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

theemathas commented Jun 18, 2026 •

edited by rustbot

Loading

lcnr left a comment •

edited by rustbot

Loading

mejrs left a comment •

edited

Loading