async-graphql: Cannot find attr `field` when using cfg_attr

I am building a library that will optionally enable async-graphql support:

[package]
name = "elastiql"
version = "0.1.0"
authors = ["William Myers <mwilliammyers@gmail.com>"]
edition = "2018"

[features]
default = ["graphql", "builder"]

graphql = ["async-graphql"]
builder = ["typed-builder"]

[dependencies]
async-graphql = { version = "1.14.*", optional = true }
base64 = "0.12"
serde = { version = "1", features = ["derive"] }
serde_json = "1"
typed-builder = { version = "0.6", optional = true }

But when I try to guard the field attribute (just like I do with builder) like this:

#[cfg_attr(feature = "graphql", async_graphql::InputObject)]
#[cfg_attr(feature = "builder", derive(typed_builder::TypedBuilder))]
#[derive(Serialize, Clone, Debug)]
pub struct NestedFilterInput {
    path: String,

    query: CompoundFilterInput,

    #[cfg_attr(feature = "graphql", field(default))]
    #[cfg_attr(feature = "builder", builder(default))]
    ignore_unmapped: bool,
}

the compiler gives me this error:

error: cannot find attribute `field` in this scope
   --> src/search/filter/mod.rs:619:37
    |
619 |     #[cfg_attr(feature = "graphql", field(default))]
    |

I have tried:

  • #[cfg_attr(feature = "graphql", async_graphql::field(default))]
    
  • #[cfg(feature = "graphql")]
    use async_graphql::*;
    
  • adding async-graphql-derive to my dependencies


I think it is because it is not a derive based proc-macro…? Are there any ways to accomplish this?

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 22 (10 by maintainers)

Commits related to this issue

Most upvoted comments

Yeah, I can help with the docs/book 😄

I probably won’t have time until this weekend though.

FYI I think I had the same issue with item attribute

This is not easy to solve. 😭

  1. For compatibility.
  2. It’s easy to use.
  3. This change is easier. 😂

But I’m not sure I’m going to make it. I’m trying.

Parsing #[cfg_attr(feature = "AAA ", field(...))] by ourselves is definitely not feasible, this is what the rust compiler should do.