use thiserror prevents re-use in piggy-back proc-macros

[drahnr]

First of all, ❤ thank you for all your work!

I recently started to create a proc-macro to piggy-back on thiserror to determine the fatality and convenient splitting of those error types ( https://github.com/drahnr/fatality ). Under the hood it generates #[derive(fatality::thiserror::Error)] annotated types, and as long as thiserror is part of the manifest in a compatible version with the re-export of fatality, everything works just fine.
As a matter of fact, I don't want the user to have to deal with this, thiserror is an impl detail that they should not be concerned with drahnr/fatality#3 .

The root cause is the assumption of having an import of thiserror in a few places in the code that generates statements like use thiserror::private::AsDynError; which are the root of the issue at hand.

Would you accept a patch to make the base of that use statement adjustable?

[dtolnay]

I would prefer not to build a workaround for this into this crate. If you are motivated to get this working, I would recommend thinking about an RFC that lets macro-generated code refer hygienically to a specific crate.

[dtolnay]

Something along the lines of rust-lang/rust#54363 (comment) would be my preferred approach, if you'd like to work on that.

[alexkirsz]

We're facing the same issue as OP. For now, we're doing use ::macro_crate::__private::thiserror;, which works well enough for our use case but pollutes the namespace.

For serde, we're using the crate attribute to specify a custom path.