Support converting between anyhow::Error and eyre::Report automatically with ?

[ten3roberts]

Using comment: #31 (comment)

[pksunkara]

@dtolnay As per your discussion, I have implemented this, but there is a small issue which I hope you can guide me:

As soon as I added your snippet, I got the following error:

error[E0119]: conflicting implementations of trait `From<_>` for type `Report`
   --> eyre/src/error.rs:503:1
    |
492 | / impl<E> From<E> for Report
493 | | where
494 | |     E: StdError + Send + Sync + 'static,
    | |________________________________________- first implementation here
...
503 | / impl<E> From<E> for Report
504 | | where
505 | |     E: Into<anyhow::Error>,
506 | |     Result<(), E>: anyhow::Context<(), E>,
    | |__________________________________________^ conflicting implementation for `Report`

So, I added #[cfg(not(feature = "anyhow"))] to the first part, but the CI is failing because downcasting is not working anymore.

I don't have enough context on this, and I was surprised that I was getting the error in the first place at all.

[yaahc]

@pksunkara the into call that converts the anyhow::Error into a Box<dyn Error + ...> calls https://docs.rs/anyhow/latest/anyhow/struct.Error.html#method.into_boxed_dyn_error internally

relevant part of docs

If a backtrace was collected during construction of the anyhow::Error, that backtrace remains accessible using the standard library Error trait’s provider API, but as a consequence, the resulting boxed error can no longer be downcast to its original underlying type.

I think we need to find a way to not break downcasting before we can use this to improve interop with anyhow.

Off of the top of my head, if the provider API is available the wrapper anyhow inserts could provide a reference to the underlying error type which we can still downcast from. If provider isn't available anyhow could maybe provide the original error directly instead of the wrapper. Iunno, feels a little hacky, hopefully david can think of a better solution.

[yaahc]

registering the blocking objection since I already commented

reason: I don't believe breaking downcasting is not an acceptable tradeoff for improved anyhow interop (open to arguments to change this position if others disagree).