Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Mar 21, 2025

Conversation

jdonszelmann
Copy link
Contributor

@jdonszelmann jdonszelmann commented Mar 19, 2025

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

Closes #138596

@rustbot
Copy link
Collaborator

rustbot commented Mar 19, 2025

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 rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) 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 Mar 19, 2025
@jdonszelmann jdonszelmann changed the title Add an attribute that makes the spans from a macro edition 2021 Add an attribute that makes the spans from a macro edition 2021, and fix pin on edition 2024 with it Mar 19, 2025
@WaffleLapkin
Copy link
Member

r? WaffleLapkin
r=me with green CI

@rustbot rustbot assigned WaffleLapkin and unassigned Noratrieb Mar 19, 2025
@rust-log-analyzer

This comment was marked as resolved.

@petrochenkov

This comment was marked as off-topic.

@Noratrieb

This comment was marked as resolved.

@petrochenkov
Copy link
Contributor

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

@Noratrieb

This comment has been minimized.

@petrochenkov
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member

m-ou-se commented Mar 19, 2025

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
Copy link
Member

m-ou-se commented Mar 19, 2025

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
Copy link
Contributor

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
Copy link
Member

m-ou-se commented Mar 19, 2025

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.

@BoxyUwU

This comment was marked as off-topic.

@bors bors merged commit 7c2475e into rust-lang:master Mar 21, 2025
6 checks passed
@rustbot rustbot added this to the 1.87.0 milestone Mar 21, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 21, 2025
Rollup merge of rust-lang#138717 - jdonszelmann:pin-macro, r=WaffleLapkin

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

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

Closes rust-lang#138596
@m-ou-se m-ou-se deleted the pin-macro branch March 26, 2025 08:31
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 28, 2025
Put pin!() tests in the right file.

In rust-lang#138717, these tests were put in `tests/pin.rs`, but they should go in `tests/pin_macro.rs`.

r? `@jdonszelmann`
@m-ou-se m-ou-se mentioned this pull request Mar 28, 2025
29 tasks
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 29, 2025
Rollup merge of rust-lang#139052 - m-ou-se:pin-macro-tests, r=joboet

Put pin!() tests in the right file.

In rust-lang#138717, these tests were put in `tests/pin.rs`, but they should go in `tests/pin_macro.rs`.

r? `@jdonszelmann`
@m-ou-se m-ou-se added beta-nominated Nominated for backporting to the compiler in the beta channel. and removed beta-nominated Nominated for backporting to the compiler in the beta channel. labels Mar 29, 2025
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 29, 2025
Add more tests for pin!().

This adds the tests suggested by `@danielhenrymantilla` in this comment: rust-lang#138717 (comment) by
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 29, 2025
Rollup merge of rust-lang#139097 - m-ou-se:pin-tests, r=WaffleLapkin

Add more tests for pin!().

This adds the tests suggested by `@danielhenrymantilla` in this comment: rust-lang#138717 (comment) by
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request Apr 2, 2025
…pkin

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

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

Closes rust-lang#138596
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request Apr 2, 2025
Put pin!() tests in the right file.

In rust-lang#138717, these tests were put in `tests/pin.rs`, but they should go in `tests/pin_macro.rs`.

r? `@jdonszelmann`
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request Apr 2, 2025
Add more tests for pin!().

This adds the tests suggested by `@danielhenrymantilla` in this comment: rust-lang#138717 (comment) by
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Apr 17, 2025
Implement `pin!()` using `super let`

Tracking issue for super let: rust-lang#139076

This uses `super let` to implement `pin!()`.

This means we can remove [the hack](rust-lang#138717) we had to put in to fix rust-lang#138596.

It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.

While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.

It'd help [the experiment](rust-lang#139076) to have `pin!()` use `super let`, so we can get some more experience with it.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 18, 2025
Implement `pin!()` using `super let`

Tracking issue for super let: rust-lang#139076

This uses `super let` to implement `pin!()`.

This means we can remove [the hack](rust-lang#138717) we had to put in to fix rust-lang#138596.

It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.

While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.

It'd help [the experiment](rust-lang#139076) to have `pin!()` use `super let`, so we can get some more experience with it.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 18, 2025
Implement `pin!()` using `super let`

Tracking issue for super let: rust-lang#139076

This uses `super let` to implement `pin!()`.

This means we can remove [the hack](rust-lang#138717) we had to put in to fix rust-lang#138596.

It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.

While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.

It'd help [the experiment](rust-lang#139076) to have `pin!()` use `super let`, so we can get some more experience with it.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 18, 2025
Implement `pin!()` using `super let`

Tracking issue for super let: rust-lang#139076

This uses `super let` to implement `pin!()`.

This means we can remove [the hack](rust-lang#138717) we had to put in to fix rust-lang#138596.

It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.

While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.

It'd help [the experiment](rust-lang#139076) to have `pin!()` use `super let`, so we can get some more experience with it.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 18, 2025
Implement `pin!()` using `super let`

Tracking issue for super let: rust-lang#139076

This uses `super let` to implement `pin!()`.

This means we can remove [the hack](rust-lang#138717) we had to put in to fix rust-lang#138596.

It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.

While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.

It'd help [the experiment](rust-lang#139076) to have `pin!()` use `super let`, so we can get some more experience with it.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 19, 2025
Implement `pin!()` using `super let`

Tracking issue for super let: rust-lang#139076

This uses `super let` to implement `pin!()`.

This means we can remove [the hack](rust-lang#138717) we had to put in to fix rust-lang#138596.

It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.

While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.

It'd help [the experiment](rust-lang#139076) to have `pin!()` use `super let`, so we can get some more experience with it.
github-actions bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request Apr 19, 2025
Implement `pin!()` using `super let`

Tracking issue for super let: rust-lang/rust#139076

This uses `super let` to implement `pin!()`.

This means we can remove [the hack](rust-lang/rust#138717) we had to put in to fix rust-lang/rust#138596.

It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.

While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.

It'd help [the experiment](rust-lang/rust#139076) to have `pin!()` use `super let`, so we can get some more experience with it.
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Apr 20, 2025
Implement `pin!()` using `super let`

Tracking issue for super let: rust-lang/rust#139076

This uses `super let` to implement `pin!()`.

This means we can remove [the hack](rust-lang/rust#138717) we had to put in to fix rust-lang/rust#138596.

It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.

While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.

It'd help [the experiment](rust-lang/rust#139076) to have `pin!()` use `super let`, so we can get some more experience with it.
ChrisDenton added a commit to ChrisDenton/rust that referenced this pull request Apr 20, 2025
…Urgau

Remove (now unused) #[rustc_macro_edition_2021] attribute

Now that rust-lang#139114 has been merged, we no longer need the temporary hack (`#[rustc_macro_edition_2021]`) that we introduced in rust-lang#138717. Time to remove it.
ChrisDenton added a commit to ChrisDenton/rust that referenced this pull request Apr 20, 2025
…Urgau

Remove (now unused) #[rustc_macro_edition_2021] attribute

Now that rust-lang#139114 has been merged, we no longer need the temporary hack (`#[rustc_macro_edition_2021]`) that we introduced in rust-lang#138717. Time to remove it.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Apr 20, 2025
Rollup merge of rust-lang#140067 - m-ou-se:remove-macro-2021-hack, r=Urgau

Remove (now unused) #[rustc_macro_edition_2021] attribute

Now that rust-lang#139114 has been merged, we no longer need the temporary hack (`#[rustc_macro_edition_2021]`) that we introduced in rust-lang#138717. Time to remove it.
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request Apr 22, 2025
Implement `pin!()` using `super let`

Tracking issue for super let: rust-lang#139076

This uses `super let` to implement `pin!()`.

This means we can remove [the hack](rust-lang#138717) we had to put in to fix rust-lang#138596.

It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.

While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.

It'd help [the experiment](rust-lang#139076) to have `pin!()` use `super let`, so we can get some more experience with it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

pin macro no longer lifetime extends argument