davidpdrsn / bae

A Rust proc-macro attribute parser inspired by Darling

bae

bae is a crate for proc macro authors, which simplifies parsing of attributes. It is heavily inspired by darling but has a significantly simpler API.

See the docs for more info.

bae's Issues

Parse attributes without prefix

I'm trying bae as an alternative to darling. With darling, I implemented prefix-less attributes for my library:

#[derive(Modal)] // My derive macro
#[name = "Modal title"]
struct MyModal {
    #[name = "First input label"]
    #[placeholder = "Your first input goes here"]
    #[min_length = 5]
    #[min_length = 500]
    first_input: String,
    #[name = "Second input label"]
    #[paragraph]
    second_input: Option<String>,
}

However, bae seems to require all attributes to be enclosed in a common identifier (the FromAttributes-derived struct name):

#[derive(bae::FromAttributes)]
struct Poise { /* ... */ }

#[poise(name = "Modal title")]
struct MyModal {
    #[poise(name = "First input label")]
    #[poise(placeholder = "Your first input goes here")]
    #[poise(min_length = 5)]
    #[poise(min_length = 500)]
    first_input: String,
    #[poise(name = "Second input label")]
    #[poise(paragraph)]
    second_input: Option<String>,
}

Implemented here:

bae/src/lib.rs

Line 167 in 3b018d1

Some(ident) if ident == #attr_name => {

Would a PR be accepted to add support for the first snippet's syntax? For example with a #[no_prefix] attribute on the FromAttributes-derived struct

Parse multiple attributes

How to parse multiple attributes into a single struct? For example

// Library proc macro code
#[derive(bae::FromAttributes)]
struct Poise {
    name: Option<syn::LitStr>,
    placeholder: Option<syn::LitStr>,
    min_length: Option<syn::LitInt>,
    max_length: Option<syn::LitInt>,
}

// User code
struct MyModal {
    #[poise(name = "First input label")]
    #[poise(placeholder = "Your first input goes here")]
    #[poise(min_length = 5)]
    #[poise(min_length = 500)]
    first_input: String,
}

When parsing the field attributes with Poise::from_attributes(&field.attrs), only the first attributes is parsed:

Poise { name: Some(LitStr { token: "First input label" }), placeholder: None, min_length: None, max_length: None, paragraph: None }

I assume this is because the parser code immediately returns upon encountering the first valid attribute:

bae/src/lib.rs

Lines 165 to 173 in 3b018d1

	for attr in attrs {
	match attr.path.get_ident() {
	Some(ident) if ident == #attr_name => {
	return Some(syn::parse2::<Self>(attr.tokens.clone())).transpose()
	}
	// Ignore other attributes
	_ => {},
	}
	}

Would a PR for parsing all valid attributes be accepted?

Support for doc comments

Hey, I can't find any support for doc comments is that intentional or something that you think is reasonable to support?

Wrong keywords in Cargo.toml

This project is neither about web nor graphql.

Multiple FromAttributes structs with same name?

Use case:

#[derive(MyDeriveMacro)]
#[my_derive_macro(/* struct attributes */)]
struct Foo {
    #[my_derive_macro(/* field attributes */)]
    bar: syn::LitIdent,
}

The set of valid attributes on the struct vs on a field is different, but the name my_derive_macro should stay the same. How to achieve this with bae? Is this the best way?:

mod struct_attrs {
    #[derive(bae::FromAttributes)]
    pub struct MyDeriveMacro { /* struct attributes */ }
}
use struct_attrs::MyDeriveMacro as StructAttrs;

mod field_attrs {
    #[derive(bae::FromAttributes)]
    pub struct MyDeriveMacro { /* field attributes */ }
}
use field_attrs::MyDeriveMacro as FieldAttrs;

A #[bae(name = "...")]/#[bae(rename = "...")]/#[bae(prefix = "...")] attribute on FromAttributes-derived structs could solve this nicely:

#[derive(bae::FromAttributes)]
#[bae(name = "my_derive_macro")]
pub struct StructAttrs { /* struct attributes */ }

#[derive(bae::FromAttributes)]
#[bae(name = "my_derive_macro")]
pub struct FieldAttrs { /* field attributes */ }

Would such a PR be accepted?

Support generating deprecation warnings on fields

It would be neat if fields could have a #[bae(deprecated)] attribute that would cause the generated attribute to show a deprecation warning when used.