You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 27, 2022. It is now read-only.
When generating a reference to a variable that's not explicitly passed in to a #[proc_macro_hack] macro, but which is present local to the call site, behavior is inconsistent with the behavior of #[proc_macro] on nightly, probably due to the enclosing macro_rules! macro. This should be documented as a limitation (or worked around, which would be great).
Example
Defining a proc_macro_hack macro like this:
// repro-impl/src/lib.rsexterncrate proc_macro;use proc_macro::*;use proc_macro_hack::proc_macro_hack;use syn;#[proc_macro_hack]pubfnrepro(input:TokenStream) -> TokenStream{letmut body :Vec<TokenTree>= Vec::<TokenTree>::new();// parse and add `a+3`let ba = TokenStream::from(syn::parse_str::<proc_macro2::TokenStream>(&"a+3").unwrap());
body.extend(ba);
body.into_iter().collect::<TokenStream>()}
// repro-test/src/main.rsexterncrate repro;fnmain(){let a = 3;let b = repro::repro!();}
Fails with:
error[E0425]: cannot find value `a` in this scope
--> repro-test\src\main.rs:5:9
|
5 | let b = repro::repro!();
| ^^^^^^^^^^^^^^^ not found in this scope
However, defining a proc_macro like this:
// repro-nightly/src/lib.rsexterncrate proc_macro;use proc_macro::*;use syn;#[proc_macro]pubfnrepro(input:TokenStream) -> TokenStream{letmut body :Vec<TokenTree>= Vec::<TokenTree>::new();// parse and add `a+3`let ba = TokenStream::from(syn::parse_str::<proc_macro2::TokenStream>(&"a+3").unwrap());
body.extend(ba);
body.into_iter().collect::<TokenStream>()}
And calling it like this:
// repro-test/src/main.rs#![feature(proc_macro_hygiene)]externcrate repro;externcrate repro_nightly;fnmain(){let a = 3;let b = repro_nightly::repro!();}
Succeeds.
The text was updated successfully, but these errors were encountered:
Thanks for the clear repro! I developed a fix to make it work, but I can't really tell how this hack might interact with some other hacks so I haven't enabled it by default. I released proc-macro-hack 0.5.6 in which #[proc_macro_hack(fake_call_site)] in repro/src/lib.rs will almost1 make your code work. Hopefully I can make this the default behavior in a later release after getting some experience with it.
1 It only works if the macro has at least one input token, which your repro does not but your real use case sounds like it always would.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When generating a reference to a variable that's not explicitly passed in to a #[proc_macro_hack] macro, but which is present local to the call site, behavior is inconsistent with the behavior of #[proc_macro] on nightly, probably due to the enclosing macro_rules! macro. This should be documented as a limitation (or worked around, which would be great).
Example
Defining a proc_macro_hack macro like this:
Exporting it like this:
And calling it like this:
Fails with:
However, defining a proc_macro like this:
And calling it like this:
Succeeds.
The text was updated successfully, but these errors were encountered: