'cargo test' with proc_macro_derive fails

[rukai]

I setup a crate using the example from http://www.ncameron.org/blog/macros-and-syntax-extensions-and-compiler-plugins-where-are-we-at/
There are no tests setup: no tests folder, no #[test] attributes.

• cargo run succeeds
• cargo test fails with: error: the #[proc_macro_derive]attribute is only usable with crates of theproc-macro crate type

Naturally I expected this error not to occur.

cargo.toml

name = "foobar"
version = "0.1.0"
authors = ["Rukai]

[lib]
proc-macro = true

lib.rs

#![feature(proc_macro, proc_macro_lib)]
#![crate_type = "proc-macro"]

extern crate proc_macro;

use proc_macro::TokenStream;

#[proc_macro_derive(B)]
pub fn derive(input: TokenStream) -> TokenStream {  
    let input = input.to_string();
    format!("{}\n impl B for A {{ fn b(&self) {{}} }}", input).parse().unwrap()
}

rust version

Run on the latest nightly via rustup:
rustc 1.14.0-nightly (3f4408347 2016-10-27) binary: rustc commit-hash: 3f4408347d2109803edbf53c89c8bce575de4b67 commit-date: 2016-10-27 host: x86_64-unknown-linux-gnu release: 1.14.0-nightly LLVM version: 3.9

[TimNN]

You can probably work around this by using #[cfg_attr(not(test), proc_macro_derive(B))] (although I haven't tested that).

[alexcrichton]

Thanks for the report! I'm not sure what the best way to solve this would be. We could either tell the compiler that --test doesn't work for these crate types, or we could tell Cargo to not test proc-macro libraries. Both should have the end goal though of having cargo test work by default.

[keeperofdakeys]

Would a simple fix for this be to add && !sess.opts.test to https://github.com/rust-lang/rust/blob/c19cb9c1/src/librustc_driver/driver.rs#L707 ? Or should syntax_ext::proc_macro_registrar::modify - where it currently panics - quietly bail out if this is a test crate?

[alexcrichton]

@keeperofdakeys I'd personally prefer for --test to keep doing the same feature gating it's doing today, so in that sense I don't think it should take the same bail-out route that rustdoc takes. Adding some logic to modify though sounds good to me.

[colin-kiegel]

I think it was wrong that this ticket was closed with #37826 since it states

this PR doesn't attempt to fix the issue itself ... just to provide a better error message.

[keeperofdakeys]

@alexcrichton Actually fixing this appears simpler than I expected. I'm guessing a return here should be enough. This will ensure all the feature gating is still done, but no expansion is performed. Did you have any further thoughts?

[alexcrichton]

@keeperofdakeys of it works it works for me!