Parse pinned local variable declarations

[frank-king]

This PR implements part of #130494, parsing let pin mut x or let pin const x in local variables that cannot be moved.

[rustbot]

r? @Noratrieb

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

[rustbot]

Some changes occurred in match checking

cc @Nadrieril

[Noratrieb]

The tracking issue only mentions constructors and reborrowing, and not pinned locals, so I don't think this should be added.
I don't even know what this should do, it is very non-obvious to me. Can you explain to me what you'd expect this to do?

[frank-king]

Compared to mut locals, pin mut locals can be borrowed by &pin mut, but cannot be moved by assignment, passed to a function, or mutable borrow &mut.

Similarly, pin const locals cannot be passed to a function, or something like Cell::take.

For example:

struct Foo;

impl Foo {
    fn by_pin_const(&pin const self) {}
    fn by_pin_mut(&pin mut self) {}
    fn by_ref(&self) {}
    fn by_mut(&mut self) {}
    fn by_value(self) {}
}

fn bar() {
    let pin mut foo = Foo; // define a pinned mutable local (cannot be moved but can be mutated)
    foo.by_pin(); // ok
    foo.by_pin_mut(); // ok
    foo.by_ref(); // ok because `Pin<Foo>` impls Deref<Target = Foo>
    foo.by_mut(); //~ ERROR cannot borrow `foo` mutably because it is pinned
    foo.by_value();  //~ ERROR cannot move `foo` because it is pinned
    foo = Foo; //~ ERROR cannot assign to `foo` because the previous value it bound has be pinned

    let pin const foo = Foo; // define a pinned immutable local (cannot be moved nor mutated)
    foo.by_pin(); // ok
    foo.by_pin_mut(); // ERROR cannot borrow `foo` mutably because it is immutably pinned
    foo.by_ref(); // ok because `Pin<Foo>` impls Deref<Target = Foo>
    foo.by_mut(); //~ ERROR cannot borrow `foo` mutably because it is immutably pinned
    foo.by_value();  //~ ERROR cannot move `foo` because it is pinned
    foo = Foo; //~ ERROR cannot assign to `foo` because the `foo` is immuable
}

[compiler-errors]

This feature needs to be gated properly so that we reject this in #[cfg]'d out code.

[rustbot]

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[bors]

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

[bmisiak]

Quite excited for this after reading Pinned Places and working through the churn/pain of removing async_trait and Box<Pin<T>>s in a major library. 🤞

[traviscross]

cc @eholk

[Noratrieb]

Sorry for the delay, I lost track of this. This is not an item on the list of #130494. Is this still something that the lang team is interested in pursuing? @traviscross @eholk

[eholk]

There's a good chance that, in the context of the pin ergonomics experiment, we'll want something like this. It seems like we'll either have it be explicit, like in this PR, or the compiler will implicitly track whether a place has been pinned. Given that the goal of the pin ergonomics experiment is to explore the space here and get some experience with it, I think it's reasonable to pursue the idea of pinned places.

[traviscross]

It's fine to include this in the scope of the experiment. My only concern would be ensuring that someone is planning to follow-up shortly to make these actually work as intended.

[bors]

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

[bors]

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

[Noratrieb]

r? compiler-errors

[bors]

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