Add an attribute that makes the spans from a macro edition 2021, and fix pin on edition 2024 with it

[jdonszelmann]

Fixes a regression, see issue below. This is a temporary fix, super let is the real solution.

Closes #138596

[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

[WaffleLapkin]

r? WaffleLapkin
r=me with green CI

[petrochenkov]

@petrochenkov do you have a constructive suggestion for this issue or just unconstructive complaints? The latter is not welcome.

I need to think.
(Not blocking since this is a regression fix.)

[petrochenkov]

One alternative not requiring compiler hacks is to put it into a separate 2021 edition crate and then reexport it from libcore, but that may (or may not) cause some larger build/infrastructure issues.

[workingjubilee]

Probably will. And no one wants to spend a day debugging the CI issues when it does. And speaking from my POV as libs reviewer, I strongly prefer core's current dependency graph to it having any dependencies at all.

[m-ou-se]

What are you people doing 🤦
I really hope this is temporary.

It really should be. If this isn't temporary, it means that Rust 2024 isn't as expressive as Rust 2021. That would be a problem!

Opened #138718 to track that.

[m-ou-se]

One alternative not requiring compiler hacks is to put it into a separate 2021 edition crate and then reexport it from libcore, but that may (or may not) cause some larger build/infrastructure issues.

Definitely considered that. But adding a dependency to core isn't trivial. And unfortunately we don't have :expr2024 in Rust 2021, so it wouldn't just be moving the enitr pin macro to a 2021 crate.

Luckily this attribute is very simple to implement, and thus simple to remove again. (It just sets the SyntaxExtension::edition field.)

[theemathas]

Is it reasonable to try running crater with the identity() fix to see how much code breaks? Broken code probably would need to look like pin!(&mut temporary()), which is kinda silly, and hopefully doesn't come up often enough to be an issue.

[m-ou-se]

Is it reasonable to try running crater with the identity() fix to see how much code breaks? Broken code probably would need to look like pin!(&mut temporary()), which is kinda silly, and hopefully doesn't come up often enough to be an issue.

Considering that pin!() is used often in aync application code (not just libraries), I think crater might not be very representative, as there might be a lot of uses in code that is not on (public) github or crates.io.

[m-ou-se]

@bors r=WaffleLapkin

[bors]

📌 Commit 0577300 has been approved by WaffleLapkin

It is now in the queue for this repository.

[danielhenrymantilla]

When I tried to work on this with my failed attempt, I thought of extra tests which seem important for pin, so you may want to add them if you like them 🙂:

fn transitive_extension {
    async fn temporary() {}

    // `pin!` witnessed in the wild being used like this, even if it yields
    // a `Pin<&mut &mut impl Unpin>`; it does work because `pin!`
    // happens to transitively extend the lifespan of `temporary()`.
    let p = pin!(&mut temporary());
    let _use = p;
}

as well as the following things which have to fail to compile to guarantee the soundness of pin!: pin! needs to consume ownership of the argument given to it, by having moved that value to its own super let local, or by having funneled it through a value expression such as { $value }.

• struct NotCopy<T>(T);
  #[allow(unused_mut)]
  let mut pointee = NotCopy(core::marker::PhantomPinned);
  pin!(pointee);
  let _moved = pointee; // Error, use of moved value.

• struct NotCopy<T>(T);
  let mut pointee = NotCopy(core::marker::PhantomPinned);
  pin!(*&mut pointee); // Error, cannot move out of `&mut`, `NotCopy` is not `Copy`.
  let _moved = pointee;

[m-ou-se]

Thanks! Would you mind putting that in a PR?