#[diagnostic(transparent)] for passthrough diagnostics

[zkat]

No description provided.

[zkat]

actuallly I don't think we need this, if we have #[error(transparent)] already...

[cormacrelf]

@zkat This is still necessary. Just placing #[error(transparent)] on a single item enum variant doesn't do anything WRT the Diagnostic implementation. It needs to generate code that implements Diagnostic through the inner type, the way thiserror's does for the Display and Error::backtrace etc implementations.

Thiserror does give you the From implementation via Variant(#[from] Inner) for free.

---

The use case for miette is pretty obvious, same as thiserror's, but for some context, I'm doing this:

#[derive(Debug, Error, Diagnostic)]
enum Diag {
    #[error(transparent)] #[diagnostic(transparent)] Error(#[from] Error),
    // The rest of the variants go here, all warnings/advice, no errors
}

// this would be weird -- you could fail your whole thing because of a warning
fn bad_function(...) -> Result<i32, Diag> {}
// this way your Err case is never a warning, so you are never in the situation where
// there is only a warning but you don't have an Ok value to continue with
fn better_function(...) -> Result<i32, Error> {}

[cormacrelf]

There is another way, which is to box all of your diagnostics and let the dynamism do the work. But sometimes you don't want to erase all the types, if you're like me (the guy from twitter who wanted to collect all the diagnostics into a Vec and expose them to library users) then maybe you just want the one type. The code goes a long way but I'm not sure.

You might also want to delegate only some of the Diagnostic implementation. I'm thinking about having a lot of different variants where practically every single one has a source, a snippet and an optional hint. Being able to forward the snippet implementation to a single struct Snip but provide a new code etc would be very useful.

[cormacrelf]

I'm having a crack at a PR for this