feat: Improve user-facing compiler errors when Pavex attribute macros return an error

[LukeMathWalker]

Context

Attribute macros replace the item they were attached to. This is not the same behaviour you get with derive macros: in that case, the decorated item is left untouched, no matter what the macro expands to.

Issue

Let's consider a simple route definition:

#[pavex::get]
pub fn my_route() -> pavex::Response {
    // [...]
}

#[pavex::get] will emit an error, since no path argument was provided.
Since it didn't expand successfully, no code will be emitted. As a consequence, there will be no definition for my_route in the crate that gets compiled by cargo.
Every single reference to my_route anywhere else in the codebase (e.g. in a unit test) will trigger an "undefined item" error from rustc.

Desired behaviour

Pavex attribute macros should always re-emit the item they were attached to in case of error, thus reducing noise for the end-user.
Otherwise, our own error gets lost in the flood of artificial issues that ended up causing by "swallowing" the item definition.

[LukeMathWalker]

There is a follow-up to the problem above: most of our attribute macros generate a strongly-typed handle to the annotated type/callable. That's also going to be referred/used, thus causing unnecessary noise when the macro returns an error and the handle definition doesn't get emitted.

It'd be ideal if we could generate the handle definition whenever we have enough information to do so.

Example

use pavex_macros::error_handler;

#[error_handler]
pub fn handler(_a: &str, _b: u64) -> pavex::Response {
    todo!()
}

The above error handler annotation is invalid—it doesn't specify which of the two inputs is an error reference.
But we have all the information we need to generate the strongly-typed handle, and we should strive to do so!

[LukeMathWalker]

Since you're on a macro diagnostic streak, I wonder if you might be interested in the follow-up too @Duckaet?

[Duckaet]

Since you're on a macro diagnostic streak, I wonder if you might be interested in the follow-up too @Duckaet?

thanks for ping, Luca

I am interested in taking the follow-up. your explanation clarifies the behavior

If there are any edge cases you think, let me know

[Duckaet]

@LukeMathWalker , i have made a pr , please review it