Add eyre::Ok

[kylewlacy]

This PR is a backport of the anyhow::Ok function (dtolnay/anyhow#192). For motivation, consider the following minimal example:

fn main() -> eyre::Result<()> {
    let f = || eyre::Ok(());

    f()?;

    Ok(())
}

Without this Ok, function, the next best way to write line 2 would be let f = || Result::<_, eyre::Error>::Ok(());, which is quite verbose! anyhow::Ok is probably the biggest pain point I've had in the cases where I've used eyre in place of anyhow.

[thenorili]

I'm struggling to understand the use case of this change, but I understand it's an anyhow feature you rely on and that somehow it works better with type inference when getting an Ok() at least though, and that compatibility with anyhow is worthwhile.

A search returns many callsites and uses of Ok(()) in the code, tests, and documentation that seem to be implicitly Result::Ok().

Can you help me understand why you've specified Result::Ok() in a couple places and not others? I wouldn't think Result::Ok() would actually specify much between core::fmt::Result and eyre::Result.

[kylewlacy]

Can you help me understand why you've specified Result::Ok() in a couple places and not others? I wouldn't think Result::Ok() would actually specify much between core::fmt::Result and eyre::Result.

It's... been a while since I made this PR, so I've lost a lot of the context. If I remember right, my intent was to make sure that code that was using the function std::Result::Ok(...) was still using the same function std::Result::Ok(...), but looking back, it actually doesn't do that (since eyre::Result shadows std::Result). Since this PR has conflicts, I'll take a second stab at it (preferring just to use the bare Ok function where possible).

[thenorili]

Can you help me understand why you've specified Result::Ok() in a couple places and not others? I wouldn't think Result::Ok() would actually specify much between core::fmt::Result and eyre::Result.

It's... been a while since I made this PR, so I've lost a lot of the context. If I remember right, my intent was to make sure that code that was using the function std::Result::Ok(...) was still using the same function std::Result::Ok(...), but looking back, it actually doesn't do that (since eyre::Result shadows std::Result). Since this PR has conflicts, I'll take a second stab at it (preferring just to use the bare Ok function where possible).

I appreciate you giving a second stab at it ^^; eyre has been a little out of water but there are a few more folks around now so we're pumping out the backlog! I think the actual conflict here was nothing, it just needed an auto-resolve and I finally got the workflow to work for that on my side : ) I'd really appreciate you checking that the actual types are correct and and not over or underspecified though.

Good luck with this, if you get stuck you can feel free to ping me and ask for help!

[thenorili]

error[E0308]: mismatched types
   --> eyre/src/lib.rs:712:9
    |
703 |     ) -> core::fmt::Result {
    |          ----------------- expected `std::result::Result<(), std::fmt::Error>` because of return type
...
712 |         Ok(())
    |         ^^^^^^ expected `Result<(), Error>`, found `Result<(), Report>`
    |
    = note: expected enum `std::result::Result<_, std::fmt::Error>`        
               found enum `std::result::Result<_, Report>`

error[E0308]: mismatched types
   --> eyre/src/lib.rs:834:9
    |
790 |     ) -> core::fmt::Result {
    |          ----------------- expected `std::result::Result<(), std::fmt::Error>` because of return type
...
834 |         Ok(())
    |         ^^^^^^ expected `Result<(), Error>`, found `Result<(), Report>`
    |
    = note: expected enum `std::result::Result<_, std::fmt::Error>`        
               found enum `std::result::Result<_, Report>`

This is the error that wanted the Result::Ok(()) specification. I think that it figures out the type this way because Result on the return type implies core::fmt::Result but Ok() implies the function defined in the same top-level scope. Now that I've looked at it it probably is fine as is, I don't think it should break other people's stuff since they aren't importing eyre::Ok() by default like we are. LGTM.

[thenorili]

LGTM, shouldn't break anyone else's stuff unless they're using eyre::*