When trying to use fehler on a method in an an #[actor] block, I ran into an unfortunate error.
The current setup of the #[actor] attribute doesn't play well with other proc macro attributes in all cases. Specifically, other attributes that modify the signature of a function won't work on function in an impl block with the #[actor] attribute. This is because the attribute on the impl block is expanded before attributes on functions within the block, meaning that the actor attribute won't see the changes that are made by the other macro.
I'm not sure how to resolve this, unfortunately. I suspect that the only answer for now is to not use attribute macros that modify the signature of functions. For example, in the case of fehler we'd have to find (or make) an alternate version with similar functionality but that doesn't implicitly modify the signature of the function. This is likely not a viable option in all cases, though, so it would be good if we could identify a solution that worked more generally.
It looks like #[actor] composes fine with tracing::instrument, so for now we're likely limited to only working with other attributes that don't modify the signature of the function.
When trying to use fehler on a method in an an
#[actor]
block, I ran into an unfortunate error.The current setup of the
#[actor]
attribute doesn't play well with other proc macro attributes in all cases. Specifically, other attributes that modify the signature of a function won't work on function in animpl
block with the#[actor]
attribute. This is because the attribute on the impl block is expanded before attributes on functions within the block, meaning that theactor
attribute won't see the changes that are made by the other macro.I'm not sure how to resolve this, unfortunately. I suspect that the only answer for now is to not use attribute macros that modify the signature of functions. For example, in the case of fehler we'd have to find (or make) an alternate version with similar functionality but that doesn't implicitly modify the signature of the function. This is likely not a viable option in all cases, though, so it would be good if we could identify a solution that worked more generally.