Implement pin-project in pattern matching for &pin mut|const T

[frank-king]

This PR implements part of #130494. It supports pin-project in pattern matching for &pin mut|const T.

Pin-projection by field access (i.e. &pin mut|const place.field) is not fully supported yet since pinned-borrow is not ready (#135731).

CC @traviscross

[rustbot]

r? @compiler-errors

rustbot has assigned @compiler-errors.
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

[bors]

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

[rustbot]

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in match checking

cc @Nadrieril

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in compiler/rustc_monomorphize/src/partitioning/autodiff.rs

cc @ZuseZ4

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

Some changes occurred in exhaustiveness checking

cc @Nadrieril

Some changes occurred in match lowering

cc @Nadrieril

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[Nadrieril]

It seems like you're implementing a sort of match ergonomics through &pin? What stage is this feature at?

I think pinnedness should be part of the binding mode instead of a separate notion. I haven't looked deeply yet but presumably this will raise questions similar to deref patterns and the recent match ergonomics changes.

cc @dianne

[dianne]

+1 to representing pinnedness as part of the binding mode.

Regarding match ergonomics interactions, I think we'll either want explicit &pin patterns too or logic for using & to match on pinned refs (sorry if that's planned already! I couldn't find it). Writing out the &s leading up to a binding enables making by-value bindings of Copy types; there's not a general way to do that in the pattern without explicit & patterns. Likewise, some patterns (such as bindings) don't automatically peel references from the scrutinee, so &pin could be useful there too.
The diagnostic pretty-printing for exhaustiveness checking uses the &pin const and &pin mut syntax in patterns; without explicit &pin const and &pin mut patterns, those might need adjusting.

Regarding deref patterns interactions, we'll probably also want pin ergonomics for deref patterns eventually. I don't think that'll be a problem, if I understand what Pin<Ptr> means (morally, their pointee's address not changing means calling Deref::deref on a Pin<Ptr> returns a reference that could be wrapped in a pin, right? I'm not too familiar with pinning). Edit: I did a bit more reading; that invariant does seem to exist, so pin-projection ergonomics for deref patterns should be fine conceptually (I think). Not sure how it'd look implementation-wise, since DerefMut wouldn't always work. We'd morally want something more like matching through Pin::as_deref_mut than matching through DerefMut::deref_mut. I'm thinking we could call <Ptr as DerefMut>::deref_mut(&mut pin.pinned) and trust that pinnedness in binding modes will keep everything safe.

[dianne]

Another ergonomics question: is there a way to get a non-pinned by-shared-ref binding when matching through &pin const T or &pin mut T if no intervening types implement Unpin? If I understand correctly, this PR would always result in &pin const bindings in that case. I'm not sure this is an issue (at least not one that needs to be designed around) but I think that's the one case where the binding could be either &pin const or &, so there's a slight awkwardness when the user wants a reference and has to use &* or Pin::get_ref.

[frank-king]

Regarding match ergonomics interactions, I think we'll either want explicit &pin patterns too or logic for using & to match on pinned refs

Does "match ergonomics" refer to rfcs#2005? I see it has been stabilized in 2018, and I'm not quite familiar with "ancient" Rust before (I started to learn Rust in 2021).

My intuition is just based on the crate pin_project. Take an example from its doc:

use std::pin::Pin;
use pin_project::pin_project;

#[pin_project(project = EnumProj)]
enum Enum<T, U> {
    Pinned(#[pin] T),
    Unpinned(U),
}

impl<T, U> Enum<T, U> {
    fn method(self: Pin<&mut Self>) {
        match self.project() {
            EnumProj::Pinned(x) => {
                let _: Pin<&mut T> = x;
            }
            EnumProj::Unpinned(y) = {
                let _: &mut U = y;
            }
        }
    }
}

It uses the #[pin] attribute to determine whether to project a field to a pinned reference Pin<&{mut} T> or a normal reference &{mut} T. That's because the proc-macro doesn't know whether such a field is Unpin. However, rustc knows it (from the U: Unpin trait bound, I think), so we can leverage such information to determine whether to project to a pinned reference or a normal reference. (That may conflict with your words "expected might not be inferred at this point; it's often not known until unifying it with the pattern's type" in #139751 (comment), and please correct me if I'm wrong)

With pin_ergonomics enabled, I expect it to be:

#![feature(pin_ergonomics)]

enum Enum<T, U> {
    // `#[pin]` is no longer needed, as we can infer from the trait bound whether `T` is `Unpin`.
    Pinned(T),
    Unpinned(U),
}

// `U: Unpin` is needed to inform the compiler that `U` can be projected to a normal reference.
impl<T, U: Unpin> Enum<T, U> {
    fn method(&pin mut self) {
        // `self.projection()` is no longer needed, as the compiler
       // would understand how to project a `&pin mut Enum<T, U>`
        match self {
            // `EnumProj` is no longer needed
            Enum::Pinned(x) => {
                // for `T: ?Unpin`, it is projected to `&pin mut T`
                let _: &pin mut T = x;
            }
            Enum::Unpinned(y) = {
                // for `U: Unpin`, it is projected to `&mut U`
                let _: &mut U = y;
            }
        }
    } 
}

That's how I implemented this PR.

[dianne]

Does "match ergonomics" refer to rfcs#2005? I see it has been stabilized in 2018, and I'm not quite familiar with "ancient" Rust before (I started to learn Rust in 2021).

That RFC is indeed pretty old, and isn't quite what's implemented in Rust 2024¹. I'm using "match ergonomics" loosely to mean a couple things (sorry for the jargon!):

• The ability to omit explicit reference patterns when matching on reference types; this allows binding by reference without explicit binding mode annotations. As I understand it, that is what this PR implements (with the addition of by-pinned-reference bindings).
• The ability to add explicit reference patterns to bind Copy types by-value. Currently in Rust 2024, this requires explicitly writing out all reference patterns leading up to a binding. Tracking Issue for match ergonomics 2024 (RFC 3627) #123076 is tracking changes to allow more flexibility with where reference patterns are written, for more "ergonomic" control of the binding mode.

From what I could tell, this PR supports the former of these but not the latter; for consistency with how matching on normal references works, I'd expect to be able to use explicit reference patterns to match on &pin (const|mut) T as well. Plus, that syntax is used (I think) by the match exhaustiveness diagnostics this PR implements for pinned refs, and I'd expect any patterns it outputs to be writable by users too.

However, rustc knows it (from the U: Unpin trait bound, I think), so we can leverage such information to determine whether to project to a pinned reference or a normal reference. (That may conflict with your words "expected might not be inferred at this point; it's often not known until unifying it with the pattern's type" in #139751 (comment), and please correct me if I'm wrong)

It should indeed be possible to utilize the U: Unpin trait bound, and at least as far as I can tell, that does seem like the smoothest way to do it from a user-facing perspective². The tricky thing I was referring to is if you're matching on something that doesn't have a fully specified type at the point you're matching on it, rust's type-checker will try to infer the type from the patterns you use. However, it doesn't know what type the pattern has until the big match on the pattern's kind field. In this case, expected will be an unknown "inference variable" (or have inference variables in it) at the point you ask whether it's Unpin, which (in this specific case of expected being uninferred) will always conservatively return false even if you'll later learn that expected is Unpin once you learn the pattern's type.

There might be additional subtleties/complications I'm not aware of, of course. I'm not deeply familiar with the trait solver, so I'm not totally sure how unambiguous you can guarantee its results to be. Hence my suggestion to raise an error when there's ambiguities.

Footnotes

1. Rust 2024's current match ergonomics for references is specified in Tracking issue for Rust 2024: Match ergonomics rules 1C/2C #131414 (edit: also the edition guide as pointed out below). This was designed to be future-compatible with Tracking Issue for match ergonomics 2024 (RFC 3627) #123076 but easier to stabilize in time for the edition. ↩

2. The one gotcha I can think of besides what I said before is that if you have a type parameter T, you have to assume it's not Unpin when type-checking, but if you perform automatic source code transformations to substitute in a type that is Unpin, it can result in changes in the pinnedness of bindings, which can cause type errors. Thus substituting in a specific type for a type parameter at the source code level would no longer be a well-typedness-preserving operation. But I'm not sure there's really a way around that other than requiring explicit annotations. Tracking Issue for match ergonomics 2024 (RFC 3627) #123076 has a similar issue when trying to get it working on pre-2024 Editions in a backwards-compatible way. ↩

[rust-bors]

☀️ Try build successful (CI)
Build commit: 28f0dba (28f0dbaea7526229cf2653f4cd50782159b61f82, parent: 647f1536d2f50b203ca9a67396225c4f7771e1c8)

[traviscross]

@bors r=Nadrieril,traviscross rollup

[bors]

📌 Commit d8ace32 has been approved by Nadrieril,traviscross

It is now in the queue for this repository.