-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
Conversation
r? @Noratrieb rustbot has assigned @Noratrieb. Use |
r? WaffleLapkin |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
I need to think. |
This comment has been minimized.
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. |
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. |
Definitely considered that. But adding a dependency to core isn't trivial. And unfortunately we don't have 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 |
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.
This comment was marked as off-topic.
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
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`
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`
Add more tests for pin!(). This adds the tests suggested by `@danielhenrymantilla` in this comment: rust-lang#138717 (comment) by
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
…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
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`
Add more tests for pin!(). This adds the tests suggested by `@danielhenrymantilla` in this comment: rust-lang#138717 (comment) by
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.
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.
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.
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.
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.
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.
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.
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.
…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.
…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.
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.
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.
Fixes a regression, see issue below. This is a temporary fix, super let is the real solution.
Closes #138596