Given a procedural macro like:
extern crate proc_macro;
use proc_macro::*;
#[proc_macro_attribute]
pub fn foo(a: TokenStream, b: TokenStream) -> TokenStream {
assert_eq!(a.to_string(), "final");
return b.into_iter().collect();
}and a consumer like:
#[foo::foo(final)]
fn main() {
#[foo::foo(final)]
fn foo() {}
}This previously compiled and succeeded on nightly-2019-07-10 but fails on nightly-2017-07-11. Bisection yields #62555 as the culprit of which #62393 is the likely true culprit.
When running if you set RUSTC_LOG=syntax you get:
INFO 2019-07-12T16:54:49Z: syntax::parse::token: cached tokens found, but they're not "probably equal", going with stringified version
which I believe means that the compiler is pretty-printing the identifier in macros as r#final instead of final.
For reference this is a pretty minimized scenario but it has broken wasm-bindgen's test suite (which uses #[wasm_bindgen(final)] throughout). @petrochenkov is this intentional? Is this something that should be fixed or "the macro parser needs to be update"?
(I'm gonna update the parser anyway but wanted to be sure to file an issue as well)
Given a procedural macro like:
and a consumer like:
This previously compiled and succeeded on nightly-2019-07-10 but fails on nightly-2017-07-11. Bisection yields #62555 as the culprit of which #62393 is the likely true culprit.
When running if you set
RUSTC_LOG=syntaxyou get:which I believe means that the compiler is pretty-printing the identifier in macros as
r#finalinstead offinal.For reference this is a pretty minimized scenario but it has broken
wasm-bindgen's test suite (which uses#[wasm_bindgen(final)]throughout). @petrochenkov is this intentional? Is this something that should be fixed or "the macro parser needs to be update"?(I'm gonna update the parser anyway but wanted to be sure to file an issue as well)