Add #[diagnostic(transparent)]

[cormacrelf]

Fixes #16.

I struggled hard naming some of the syntax structs/enums so rename them if you can think of something better. I also didn't implement it for single field structs, mainly because I couldn't be bothered. The only reason I can imagine that being useful is wrapping a foreign diagnostic type, and adding impls for std traits like PartialEq, etc. If anyone needs that it wouldn't be hard.

[zkat]

Isn't single field structs (newtypes) literally one of the main use cases for transparent?

[cormacrelf]

Yeah I guess, I'll add it lol

[zkat]

This looks good. Do you mind fixing the tests?

[cormacrelf]

It's just clippy I think, but yep

Once I do, hold off merging for a sec, I've got something else to show you first. I think it solves the issue I raised in #16 about being able to forward just the snippets and override whatever else. Probably a separate PR but you should see it I think

[cormacrelf]

Ok clippy done. My extra work is over at https://github.com/cormacrelf/miette/tree/forwarding.

This PR just gives you #[diagnostic(transparent)], which does not accept any other args.

The forwarding branch, in addition to that, adds a forward(field_name) arg that must be used with a code(...) like any other arg. When you supply it, it makes any unspecified things forward their implementation to the specified field. It works with named and unnamed (forward(0)) structs and enum variants. The test suite shows what you can do with it -- the ForwardsTo struct is used for the snippets, all the other bits of info can be overridden.

The question before we land this PR is a bikeshed, whether these two different argument names for arguably the same functionality are a good idea or not. Which is preferable of these?

• Only diagnostic(transparent)
• diagnostic(transparent), diagnostic(code(...), forward(field_name)) as described
• diagnostic(transparent), diagnostic(code(...), transparent(field_name))
• diagnostic(transparent), diagnostic(code(...), default(field_name). I kinda like this but I only just thought of it.

What do you reckon? Not a blocker here because all the real options include this PR as-is IMO. But there you go.

---

(Also, while I was testing this stuff I fixed a couple of things with the thiserror-style display, which worked for the crazy test cases at the top but not simple help("{1}"), which would complain about (1) commas and (2) unnamed tuple args being out of order because HashSet was being used to generate them. I can port those fixes in any case.)

[zkat]

idk seems fine. Let's try it out!

[zkat]

This has been released as part of [email protected]