The `nightly` features breaks otherwise working code after upgrading to syn 0.14

[konstin]

After upgrading to syn 0.14 (diff), activating the nightly feature breaks otherwise working code with a nonsensical error message.

cargo -V: cargo 1.28.0-nightly (e2348c2db 2018-06-07)
rustc -V: rustc 1.28.0-nightly (8afb89493 2018-06-08)

Setup for reproducing:

git clone https://github.com/konstin/capybara
cd capybara
git clone https://github.com/konstin/helix
cd helix
git checkout rebase1
cd ../tests

Without the nightly feature, cargo rustc --features capybara/ruby works just fine, but after activating that feature it in capybara-derive/Cargo.toml (sed -i 's/version = "0.4"/version = "0.4", features = ["nightly"]/' ../capybara-derive/Cargo.toml), the compilation fails with the following error:

error[E0423]: expected value, found module `helix`
  --> tests/src/lib.rs:19:1
   |
19 | #[capybara_bindgen]
   | ^^^^^^^^^^^^^^^^^^^
   | |
   | `self` value is only available in methods with `self` parameter
   | help: try: `self.helix`

error: aborting due to previous error

While there is a module (or rather a crate) helix in scope, this error message is still nonsensical since helix is always properly used as value (expanded code).

I'm not sure if this is a bug in the compiler, in proc-macro2, in syn or in quote, but since it needs the nightly feature in proc-macro2, I'm reporting this here.

[dtolnay]

I see you are using syn::parse_str(...).unwrap() to build syntax trees. This is currently implemented through proc_macro::TokenStream::from_str which we have discovered has some extremely confusing hygiene behavior. This is being tracked for the compiler in rust-lang/rust#50050. I filed dtolnay/syn#444 to work around proc_macro's behavior in syn::parse_str in the next breaking version of Syn.

You generally want to use parse_quote! instead of from_str when the input is statically known. It should work with parse_quote! { helix: ::Metadata }.

[konstin]

Thank you very much, parse_str was indeed the culprit! Closing this in favour of dtolnay/syn#444 then.

FWIW knowing that it is about Span I found that you can spot those cases easily using the debug representation of Spans:

fn print_token_stream(tokens: TokenStream, level: usize) {
    for token in tokens.into_iter() {
        match token {
            proc_macro2::TokenTree::Group(ref group) => {
                let (open, close) = match group.delimiter() {
                    proc_macro2::Delimiter::Parenthesis => ("(", ")"),
                    proc_macro2::Delimiter::Brace => ("{", "}"),
                    proc_macro2::Delimiter::Bracket => ("(", ")"),
                    proc_macro2::Delimiter::None => ("Ø", "Ø"),
                };
                println!("{:>2}: {:<30} {:?}", level, open, token.span());
                print_token_stream(group.stream(), level + 1);
                println!("{:>2}: {:<30} {:?}", level, close, token.span());
            }
            _ => {
                println!("{:>2}: {:<30} {:?}", level, token, token.span());
            }
        };
    }
}