Avoiding type annotations when using ResultExt::context methods

[jess-sol]

I'm migrating away from using mostly whatever type errors, to more structured errors. One error uses #[context(false)] to simplify passing a Snafu error from a child module, like:

use snafu::{ResultExt, Snafu};

fn main() -> Result<(), Error> {
    other::test()?;
    std::fs::read_to_string("").whatever_context("test")?; // Fails
    std::fs::read_to_string("").whatever_context::<_, Error>("test")?; // Works
    Ok(())
}

#[derive(Debug, Snafu)]
pub(crate) enum Error {
    #[snafu(context(false), display("{source}"))]
    TypeAError { source: other::NestedError },

    #[snafu(whatever, display("{message}"))]
    Whatever {
        message: String,
        #[snafu(source(from(Box<dyn std::error::Error + Send + Sync>, Some)))]
        source: Option<Box<dyn std::error::Error + Send + Sync>>,
    },
}

mod other {
    #[derive(Debug, snafu::Snafu)]
    pub(super) enum NestedError {
        Test { source: std::io::Error },
    }

    pub(super) fn test() -> Result<(), NestedError> {
        Ok(())
    }
}

But it gives the error:

error[E0283]: type annotations needed
  --> src/main.rs:5:33
   |
5  |     std::fs::read_to_string("").whatever_context("test")?; // Fails
   |                                 ^^^^^^^^^^^^^^^^        - type must be known at this point
   |                                 |
   |                                 cannot infer type of the type parameter `E2` declared on the method `whatever_context`
   |
note: multiple `impl`s satisfying `Error: From<_>` found
  --> src/main.rs:10:17
   |
10 | #[derive(Debug, Snafu)]
   |                 ^^^^^ in this derive macro expansion
   |
  ::: ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/snafu-derive-0.7.5/src/lib.rs:16:1
   |
16 | pub fn snafu_derive(input: TokenStream) -> TokenStream {
   | ------------------------------------------------------ in this expansion of `#[derive(Snafu)]`
   = note: and more `impl`s found in the following crates: `core`:
           - impl<T> From<!> for T;
           - impl<T> From<T> for T;
   = note: required for `Result<(), Error>` to implement `FromResidual<Result<Infallible, _>>`
help: consider specifying the generic arguments
   |
5  |     std::fs::read_to_string("").whatever_context::<&str, E2>("test")?; // Fails
   |                                                 ++++++++++++

Is there an alternative to eliminating all whatever_context calls, or typehinting them?

[shepmaster]

Oh, that's an interesting problem. A slightly reduced case:

use snafu::prelude::*;

fn main() -> Result<(), Error> {
    std::fs::read_to_string("").whatever_context("test")?;
    Ok(())
}

#[derive(Debug, Snafu)]
pub(crate) enum Error {
    #[snafu(context(false), display("{source}"))]
    Other { source: OtherError },

    #[snafu(whatever, display("{message}"))]
    Whatever {
        message: String,
        #[snafu(source(from(Box<dyn std::error::Error + Send + Sync>, Some)))]
        source: Option<Box<dyn std::error::Error + Send + Sync>>,
    },
}

#[derive(Debug, Snafu)]
struct OtherError;

Let's check out the signature:

fn whatever_context<S, E2>(self, context: S) -> Result<T, E2>
where
    S: Into<String>,
    E2: FromString,
    E: Into<E2::Source>,

• It takes in an argument that can be converted into a String
• It returns some error that can be created from a String.
• The source error needs to be able to be converted to the destination error's source

There's also the ? at the end of the line, which involves another call to Into::into for the error type. That means that there's quite a lot of generics and type inference going on here.

I think the key thing that's happening here is:

note: multiple impls satisfying Error: From<_> found

Indeed, adding context(false) generates this code:

impl ::core::convert::From<OtherError> for Error

If we replace the ? operator with almost the same thing that doesn't use Into, the code compiles:

match std::fs::read_to_string("").whatever_context("test") {
    Ok(v) => v,
    Err(e) => return Err(e),
};

I guess that indicates one solution — you could create your own try macro that doesn't convert the error. Then one type will be pinned down and inference will work. This is actually a known technique for some high-performance code, but not very common.

---

Sorry for missing this post for so long!

[jess-sol]

I hadn't thought of a custom try macro, that's a good idea. I ended up just type-hinting where necessary, it wasn't that painful; and the code should be refactored out over time anyways.

I appreciate the input