Temporarily prohibit proc macro attributes placed after derives#54277
Merged
bors merged 1 commit intorust-lang:masterfrom Sep 17, 2018
Merged
Temporarily prohibit proc macro attributes placed after derives#54277bors merged 1 commit intorust-lang:masterfrom
bors merged 1 commit intorust-lang:masterfrom
Conversation
... and also proc macro attributes used together with test/bench.
Contributor
Author
petrochenkov
added
the
S-waiting-on-review
Member
|
@bors: r+ p=1 |
Collaborator
|
📌 Commit 229df02 has been approved by |
bors
added
S-waiting-on-bors
Collaborator
bors
added a commit
that referenced
this pull request
Sep 17, 2018
Temporarily prohibit proc macro attributes placed after derives ... and also proc macro attributes used together with `#[test]`/`#[bench]`. Addresses item 6 from #50911 (comment). The end goal is straightforward predictable left-to-right expansion order for attributes. Right now derives are expanded last regardless of their relative ordering with macro attributes and right now it's simpler to temporarily prohibit macro attributes placed after derives than changing the expansion order. I'm not sure whether the new beta is already released or not, but if it's released, then this patch needs to be backported, so the solution needs to be minimal. How to fix broken code (derives): - Move macro attributes above derives. This won't change expansion order, they are expanded before derives anyway. Using attribute macros on same items with `#[test]` and `#[bench]` is prohibited for similar expansion order reasons, but this one is going to be reverted much sooner than restrictions on derives. How to fix broken code (test/bench): - Enable `#![feature(plugin)]` (don't ask why). r? @ghost
Collaborator
|
☀️ Test successful - status-appveyor, status-travis |
petrochenkov
added a commit
to petrochenkov/rust
that referenced
this pull request
Oct 5, 2018
The restrictions were introduced in rust-lang#54277 and no longer necessary now because legacy plugins are now expanded in usual left-to-right order
eddyb
reviewed
Feb 15, 2019
| fn deref_mut(&mut self) -> &mut T { | ||
| &mut self.ptr | ||
| } | ||
| } |
Member
There was a problem hiding this comment.
This was intentionally not implemented, but I'm considering ways in which we can make ASTs fully immutable (and interned, I suppose).
rust-cloud-vms bot
pushed a commit
to aDotInTheVoid/rust
that referenced
this pull request
Apr 2, 2024
`P<T>` has implemented `DerefMut` since rust-lang#54277. While this was lamented at the time [1], rustc now relies on it extensively via the many implementors of MutVisitor. Updates the docs to reflect that `P<T>` is fundamentally mutable, and a few other cleanups to make them nicer to browse. [1]: rust-lang#54277 (comment) [2]: https://doc.rust-lang.org/1.77.1/nightly-rustc/rustc_ast/mut_visit/trait.MutVisitor.html#implementors
rust-cloud-vms bot
pushed a commit
to aDotInTheVoid/rust
that referenced
this pull request
Apr 2, 2024
`P<T>` has implemented `DerefMut` since rust-lang#54277. While this was lamented at the time [1], rustc now relies on it extensively via the many implementors of MutVisitor [2]. Updates the docs to reflect that `P<T>` is fundamentally mutable, and a few other cleanups to make them nicer to browse. [1]: rust-lang#54277 (comment) [2]: https://doc.rust-lang.org/1.77.1/nightly-rustc/rustc_ast/mut_visit/trait.MutVisitor.html#implementors
rust-cloud-vms bot
pushed a commit
to aDotInTheVoid/rust
that referenced
this pull request
Apr 3, 2024
`P<T>` has implemented `DerefMut` since rust-lang#54277. While this was lamented at the time [1], rustc now relies on it extensively via the many implementors of MutVisitor [2]. Updates the docs to reflect that `P<T>` is fundamentally mutable, and a few other cleanups to make them nicer to browse. [1]: rust-lang#54277 (comment) [2]: https://doc.rust-lang.org/1.77.1/nightly-rustc/rustc_ast/mut_visit/trait.MutVisitor.html#implementors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Apr 3, 2024
rustc_ast: Update `P<T>` docs to reflect mutable status. `P<T>` has implemented `DerefMut` since rust-lang#54277. While this was lamented at the time [1], rustc now relies on it extensively via the many implementors of MutVisitor [2]. Updates the docs to reflect that `P<T>` is fundamentally mutable, and a few other cleanups to make them nicer to browse. [1]: rust-lang#54277 (comment) [2]: https://doc.rust-lang.org/1.77.1/nightly-rustc/rustc_ast/mut_visit/trait.MutVisitor.html#implementors r? `@Nilstrieb`
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 3, 2024
Rollup merge of rust-lang#123393 - aDotInTheVoid:ast-p-docs, r=Nilstrieb rustc_ast: Update `P<T>` docs to reflect mutable status. `P<T>` has implemented `DerefMut` since rust-lang#54277. While this was lamented at the time [1], rustc now relies on it extensively via the many implementors of MutVisitor [2]. Updates the docs to reflect that `P<T>` is fundamentally mutable, and a few other cleanups to make them nicer to browse. [1]: rust-lang#54277 (comment) [2]: https://doc.rust-lang.org/1.77.1/nightly-rustc/rustc_ast/mut_visit/trait.MutVisitor.html#implementors r? `@Nilstrieb`
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
... and also proc macro attributes used together with
#[test]/#[bench].Addresses item 6 from #50911 (comment).
The end goal is straightforward predictable left-to-right expansion order for attributes.
Right now derives are expanded last regardless of their relative ordering with macro attributes and right now it's simpler to temporarily prohibit macro attributes placed after derives than changing the expansion order.
I'm not sure whether the new beta is already released or not, but if it's released, then this patch needs to be backported, so the solution needs to be minimal.
How to fix broken code (derives):
Using attribute macros on same items with
#[test]and#[bench]is prohibited for similar expansion order reasons, but this one is going to be reverted much sooner than restrictions on derives (UPDATE: reverted in #54336).How to fix broken code (test/bench):
#.r? @ghost