Interacting with attribute macros

[Huliiiiii]

Might there be a way to work with attribute macros that add variants? Currently it's generating impl blocks before applying the attribute macro, resulting in missing match arms.

[mcmah309]

Could you give an example? It has to do with the order in which macros are applied- from the outside in. So maybe.

[Huliiiiii]

#[proc_macro_attribute]
pub fn add_field(_attr: TokenStream, item: TokenStream) -> TokenStream {
    let mut input = parse_macro_input!(item as ItemEnum);

    let new_variant = syn::Variant {
        attrs: vec![],
        ident: Ident::new("Foo", proc_macro2::Span::call_site()),
        fields: Fields::Unit,
        discriminant: None,
    };

    input.variants.push(new_variant);

    quote!(#input).into()
}

error_set! {
    #[add_field]
    Error = {
        Bar
    };
}

[mcmah309]

I think this may be a limitation of Rust's macro system, since the outside macro is applied first. Which is desired if you don't want to add a field, since the enum will be resolved before the macro is applied. A possible solution for the reverse would be to move error_set to a more Rust like syntax and inside a mod

#[error_set]
#[add_field]
mod x {
    // #[parts(...)] // new syntax for merging error parts
    #[add_field_marker]
    enum Error {
        Bar
   }
}

This would be a pretty big change to this crate. Before considering such a change, I would like to see a real use case that would benefit from this. Also , off the top of my head, it would likely require a different marker attribute to handle generics in the same way.

[mcmah309]

Does this not work for your use case?

error_set! {
    ErrorBase = {
        A(ErrorA),
        B(ErrorB),
        UnitField
    };

    Error = {
        OtherVariant
    } || ErrorBase;
}

[Huliiiiii]

No, I implemented some traits for ErrorBase. If I composite them like this, I have to re-implement those traits with same match arms on every inherited Error.

[mcmah309]

How about?

let x: Error = y.into::<ErrorBase>().into()

y.into::<ErrorBase>()?;

Sounds like we have 3 solutions here.

1. At the callsite (the above)
2. Error aggregation and trait re-implementation
3. From overriding (your current solution)

Given this, I'm not sure supporting something like

#[from(nested)]

Is needed. I have never used this pattern, but I could be the odd one out. If this is more common in the wild, I would be open to supporting it.

[Huliiiiii]

Although many people think so, into is not actually a generic function 😂. In fact, we have to call it like this:

result.map_err(Into::<ErrorBase>::into())?;

In my case, for example:

let mut file = File::create(path).await.map_err(Into::<MyError>::into())?;
file.write_all(&data).await.map_err(Into::<MyError>::into())?;
file.flush().await.map_err(Into::<MyError>::into())?;

So, for me, disabling the From trait implement generated by macro and implementing a generic From trait is a much cleaner option.
And I'm not sure how common this is in the wild either, maybe I'm that odd one out.

[mcmah309]

Although many people think so, into is not actually a generic function

Yes, I misremembered the correct syntax in my previous reply.

So, for me, disabling the From trait implement generated by macro and implementing a generic From trait is a much cleaner option.

Sounds reasonable.