Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generic parameter definitions are not cfg-stripped before #[derive] macros are invoked #75930

Closed
Aaron1011 opened this issue Aug 26, 2020 · 1 comment · Fixed by #76010
Closed
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros C-bug Category: This is a bug.

Comments

@Aaron1011
Copy link
Member

The following code (repository at https://github.com/Aaron1011/derive-bug):

// lib.rs
use proc_macro::TokenStream;

#[proc_macro_derive(MyDerive)]
pub fn my_derive(input: TokenStream) -> TokenStream {
    println!("Derive input: {}", input);
    TokenStream::new()
}


// main.rs

#[derive(derive_bug::MyDerive)]
struct Foo<#[cfg(FALSE)] T> {
    #[cfg(FALSE)] field: T,
    val: String,
    array: [u8; {
        #[cfg(FALSE)] struct Bar;
        0
    }]
}

fn main() {}

produces the following output:

Derive input: struct Foo < #[cfg(FALSE)] T > { val : String, array : [u8 ; { 0 }], }

Note how all #[cfg(FALSE)] targets are stripped, except for the generic parameter T. This seems quite inconsistent.

Tested on rustc 1.47.0-nightly (de521cbb3 2020-08-21)

@Aaron1011 Aaron1011 added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. A-proc-macros Area: Procedural macros labels Aug 26, 2020
@petrochenkov
Copy link
Contributor

The relevant code is impl<'a> MutVisitor for StripUnconfigured<'a>, it's quite possible that cfgs are not expanded in a bunch of other positions as well. (I never got to auditing that code.)

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Aug 30, 2020
…petrochenkov

Run cfg-stripping on generic parameters before invoking derive macros

Fixes rust-lang#75930

This changes the tokens seen by a proc-macro. However, ising a `#[cfg]` attribute
on a generic paramter is unusual, and combining it with a proc-macro
derive is probably even more unusual. I don't expect this to cause any
breakage.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Aug 31, 2020
…petrochenkov

Run cfg-stripping on generic parameters before invoking derive macros

Fixes rust-lang#75930

This changes the tokens seen by a proc-macro. However, ising a `#[cfg]` attribute
on a generic paramter is unusual, and combining it with a proc-macro
derive is probably even more unusual. I don't expect this to cause any
breakage.
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 1, 2020
…trochenkov

Run cfg-stripping on generic parameters before invoking derive macros

Fixes rust-lang#75930

This changes the tokens seen by a proc-macro. However, ising a `#[cfg]` attribute
on a generic paramter is unusual, and combining it with a proc-macro
derive is probably even more unusual. I don't expect this to cause any
breakage.
@bors bors closed this as completed in a97dcfa Sep 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros C-bug Category: This is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants