Pass value_changed to macro_rules! macros#1
Open
Aaron1011 wants to merge 1 commit intosammhicks:masterfrom
Open
Pass value_changed to macro_rules! macros#1Aaron1011 wants to merge 1 commit intosammhicks:masterfrom
value_changed to macro_rules! macros#1Aaron1011 wants to merge 1 commit intosammhicks:masterfrom
Conversation
In Rust, variable identifiers in a `macro_rules!` body are resolved
in the scope of tht body - they cannot see through to the caller's body.
For example, the following code errors:
`rust
macro_rules! weird_ident {
() => { my_ident; }
}
fn main() {
let my_ident = 1;
weird_ident!();
}
`
However, due to a compiler bug (rust-lang/rust#43081),
this kind of code current compiles when a procedural macro is invoked by
a `macro_rules!` macro. Eventually, this will cause a compilation error.
In the `color!` and `slider!` macro, you're currently writing an expression
involving `value_changed`, and passing it to a procedural macro (`html!`).
However, `value_changed` comes from the body of the caller of `color!`/`slider!`,
so this code will stop compiling once the compiler bug is fixed.
Fortunately, the identifier of `value_changed` can be passed into
`color!` and `slider!`. This modified code will with the current version of
Rust, as well as future version that causes the old code into an error.
I also ran `cargo update` to bump the dependencies in your Cargo.lock.
This will allow your crate to continue to compile when the compiler bug is fixed,
as you are depending on some crates (e.g. `syn`) that have released updates
to address the issue.
Feel free to ask me about any questions you may have. For more details,
see rust-lang/rust#72622
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 23, 2020
…d, r=petrochenkov Re-land PR rust-lang#72388: Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro` PR rust-lang#72388 allowed us to preserve the original `TokenStream` in more cases during proc-macro expansion, but had to be reverted due to a large number of regressions (See rust-lang#72545 and rust-lang#72622). These regressions fell into two categories 1. Missing handling for `Group`s with `Delimiter::None`, which are inserted during `macro_rules!` expansion (but are lost during stringification and re-parsing). A large number of these regressions were due to `syn` and `proc-macro-hack`, but several crates needed changes to their own proc-macro code. 2. Legitimate hygiene issues that were previously being masked by stringification. Some of these were relatively benign (e.g. [a compiliation error](paritytech/parity-scale-codec#210) caused by misusing `quote_spanned!`). However, two crates had intentionally written unhygenic `macro_rules!` macros, which were able to access identifiers that were not passed as arguments (see rust-lang#72622 (comment)). All but one of the Crater regressions have now been fixed upstream (see https://hackmd.io/ItrXWRaSSquVwoJATPx3PQ?both). The remaining crate (which has a PR pending at sammhicks/face-generator#1) is not on `crates.io`, and is a Yew application that seems unlikely to have any reverse dependencies. As @petrochenkov mentioned in rust-lang#72545 (comment), not re-landing PR rust-lang#72388 allows more crates to write unhygenic `macro_rules!` macros, which will eventually stop compiling. Since there is only one Crater regression remaining, since additional crates could write unhygenic `macro_rules!` macros in the time it takes that PR to be merged.
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
1 participant
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.
In Rust, variable identifiers in a
macro_rules!body are resolvedin the scope of tht body - they cannot see through to the caller's body.
For example, the following code errors:
However, due to a compiler bug (rust-lang/rust#43081),
this kind of code current compiles when a procedural macro is invoked by
a
macro_rules!macro. Eventually, this will cause a compilation error.In the
color!andslider!macro, you're currently writing an expressioninvolving
value_changed, and passing it to a procedural macro (html!).However,
value_changedcomes from the body of the caller ofcolor!/slider!,so this code will stop compiling once the compiler bug is fixed.
Fortunately, the identifier of
value_changedcan be passed intocolor!andslider!. This modified code will with the current version ofRust, as well as future version that causes the old code into an error.
I also ran
cargo updateto bump the dependencies in your Cargo.lock.This will allow your crate to continue to compile when the compiler bug is fixed,
as you are depending on some crates (e.g.
syn) that have released updatesto address the issue.
Feel free to ask me about any questions you may have. For more details,
see rust-lang/rust#72622