Process cfg_attr during expansion

[kmcallister]

macro_rules! borked {
    () => {
        #[derive(Debug)] pub struct Good;
        #[cfg_attr(not(test), derive(Debug))] pub struct Bad;
    }
}

borked!();

fn main() {
    println!("{:?}", Good);
    println!("{:?}", Bad);
}

produces

foo.rs:12:22: 12:25 error: the trait `core::fmt::Show` is not implemented for the type `Bad` [E0277]  
foo.rs:12     println!("{:?}", Bad);  
                               ^~~  

I think what happens is the following:

• The first cfg stripping pass runs. At this point the macro body is just a token tree, and there's no way for cfg stripping to work out what # [ cfg_attr ( not ( test ) ... means.
• Syntax expansion runs. The macro emits two items. One has a derive attribute, which matches a Decorator in the syntax environment, so that extension also runs. There's no extension named cfg_attr so that attribute has no effect on expansion.
• The post-expansion cfg stripping pass runs. The second attribute turns into #[derive(Debug)] but not in time for syntax expansion to notice it.

Previously, cfg_attr was a syntax extension, which had numerous drawbacks, but handled this case correctly.

The somewhat obvious fix is to re-run cfg_attr processing on the AST subtree produced by every macro expansion, but I'd like to think about this more. I'd also like to know whether it's something people often run into in practice.

Was mentioned on #19372. cc @sfackler, @SergioBenitez

[mathall]

I can't answer whether it's something people often run into in practice, but I have run into this bug myself.

[kmcallister]

Interesting; can you tell me more about the circumstances?

[mathall]

I'm using the bitflags macro which generates a struct and allows me to declare decorators for that struct. Decorators such as #[cfg_attr(not(test), derive(Debug))].

[DanielKeep]

I've just run into this. I'm writing some FFI bindings that involve gating pretty much every function and type. As such, I wrote the following to attach attributes to groups of items:

macro_rules! attr_block {
    ($(#[$attrs:meta])* {}) => {};

    (
        $(#[$attrs:meta])* {
            $it:item $($tail:tt)*
        }
    ) => {
        $(#[$attrs])*
        $it

        attr_block! { $(#[$attrs])* {$($tail)*} }
    };
}

All is well until I started adding #[derive(..)]s, at which point the wheels fell off.

[DanielKeep]

This also means that custom_derive! is fundamentally incompatible with #[cfg(..)], assuming you're using any built-in derives. As far as I can see, there's no way to work around this.

[durka]

I have run into this in practice as well, I was trying to write a similar macro to @DanielKeep. I settled on making an inner module, but it's not a perfect solution in many ways. It would come up with crates like cfg-if as well.

One really vexing thing about this bug is it's a silent failure. At least rustc should output a warning when it drops a cfg/cfg_attr without interpreting it.

[Kimundi]

I'm currently looking into how to possibly fix this - it would likely involve restructuring how the compiler processes the config and expansion phases.

[Kimundi]

cc @nrc

[Amanieu]

I just ran into this issue. Here is basically what I was trying to do:

macro_rules! foo {
    () => {
        #[cfg(feature = "nightly")]
        const fn bar() {}
        #[cfg(not(feature = "nightly"))]
        fn bar() {}
    };
}
foo!();

This fails with const fn is unstable even though the const fn should have been eliminated by the #[cfg].

[tikue]

@Amanieu just hit the same issue.

[Kimundi]

Hm, totally forgot that I was working on this at some point... If anyone had been waiting on me, I think I'd have to start work on this from scratch.

[jseyfried]

This was fixed in #33706.

[durka]

Awesome, I didn't expect this to actually get fixed!
On May 28, 2016 21:02, "Jeffrey Seyfried" notifications@github.com wrote:

This was fixed in #33706 #33706.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#22250 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAC3nw_uG11kkqLPkWu4hOiD8SmHyG4gks5qGOWOgaJpZM4Df3US
.

[Kimundi]

Nice!

[vi]

Shall this issue be closed?