Add an attribute that makes the spans from a macro edition 2021, and fix pin on edition 2024 with it by jdonszelmann · Pull Request #138717 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation21 Commits4 Checks6 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Fixes a regression, see issue below. This is a temporary fix, super let is the real solution.
Closes #138596
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
Area: Attributes (`#[…]`, `#![…]`)
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
Relevant to the library team, which will review and decide on the PR/issue.
labels
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
This was referenced
Mar 19, 2025
r? WaffleLapkin
r=me with green CI
This comment was marked as resolved.
This comment was marked as off-topic.
This comment was marked as resolved.
@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.)
This comment has been minimized.
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.
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.
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.
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.)
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.
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.
This comment was marked as off-topic.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
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
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
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
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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request
…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
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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
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 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 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
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 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 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
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 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 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
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 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 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
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 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 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
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 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 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
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 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 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
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 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 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
…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
…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
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
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 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 to have pin!() use super let, so we can get some more experience with it.
lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request
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 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 to have pin!() use super let, so we can get some more experience with it.
Labels
Area: Attributes (`#[…]`, `#![…]`)
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the compiler team, which will review and decide on the PR/issue.
Relevant to the library team, which will review and decide on the PR/issue.