#serde #dependency-injection #lazy-evaluation #thread-safe #builder

fieldx_aux

Various types and tools useful for fieldx crates and, potentially, to users of fieldx

11 releases

new 0.1.14 Apr 19, 2025
0.1.12 Mar 21, 2025
0.1.8 Dec 5, 2024
0.1.7 Nov 22, 2024

#478 in Procedural macros

Download history 3/week @ 2025-01-05 115/week @ 2025-01-12 24/week @ 2025-01-19 1/week @ 2025-01-26 14/week @ 2025-02-02 242/week @ 2025-02-09 405/week @ 2025-02-16 53/week @ 2025-02-23 14/week @ 2025-03-02 2/week @ 2025-03-09 188/week @ 2025-03-16 77/week @ 2025-03-23 14/week @ 2025-03-30 5/week @ 2025-04-06 85/week @ 2025-04-13

348 downloads per month
Used in 4 crates (3 directly)

Custom license

90KB
2.5K SLoC

fieldx_aux

Helper module for the fieldx crate and for any 3rd party crates, extending its functionality.

fieldx itself is heavily based on darling crate which simplifies development of proc-macros quite a lot. But it also imposes some constraints on attribute arguments syntax. This crate aims at overcoming these limitations and providing support for some kinds of attributes required to implement fieldx.

Here is a little break down of what is provided:

  • support for nested arguments, i.e. those that look like arg1("value", trigger, subarg(...))
  • support for some syntax elements that are not on the darling crate menu: some_type(crate::types::Foo), error(crate::error::Error, crate::error::Error::SomeProblem("with details"))[^tuple]
  • a set of types implementing standard fieldx arguments like helpers, or literal values, etc.

[^tuple]: Here, the first argument of error()Error — is an enum; SomeProblem is a variant.

Usage

Let's say we're implementing a field-level attribute foo using darling::FromField trait. And we want it to take these arguments:

  • trigger which would let turn some functionality on or off
  • action to specify a method with special meaning
  • comment with some text
  • vis to specify if field-related code must be public and if yes then what kind of pub we need

A field declaration may take the following form with the attribute:

    #[foo(
        trigger,
        action("method_name", private),
        comment("Whatever we consider useful."),
        vis(pub(crate))
    )]
    bar: usize,

For this we'd need the following declaration somewhere in our proc-macro implementation:

#derive(FromField)
#[darling(attributes(foo))]
struct FooField {
    // ... skipping some darling-default fields ...

    trigger: Option<FXBool>,
    action: Option<FXHelper>,
    comment: Option<FXString>,
    vis: Option<FXSynValue<syn::Visibility>>,
}

That's all, this crate will take the burden of implementing the arguments from you!

Dependencies

~0.6–1MB
~23K SLoC