impl From<string::ParseError> for Error does not compile

[dtolnay]

Heads up that this impl fails to compile on the most recent nightly, currently rustc 1.41.0-nightly (797fd9262 2019-11-26).

heim/heim-common/src/errors.rs

Lines 117 to 121 in 47f0f57

	impl From<string::ParseError> for Error {
	fn from(e: string::ParseError) -> Self {
	Error::Other(Box::new(e))
	}
	}

When building without cap-lints=allow the error is:

error: unreachable call
   --> heim-common/src/errors.rs:119:22
    |
119 |         Error::Other(Box::new(e))
    |                      ^^^^^^^^ - any code following this expression is unreachable
    |                      |
    |                      unreachable call
    |
note: lint level defined here
   --> heim-common/src/lib.rs:7:5
    |
7   |     unused,
    |     ^^^^^^
    = note: `#[deny(unreachable_code)]` implied by `#[deny(unused)]`

With cap-lints it is:

error[E0277]: the trait bound `(): std::error::Error` is not satisfied
   --> heim-common/src/errors.rs:119:22
    |
119 |         Error::Other(Box::new(e))
    |                      ^^^^^^^^^^^ the trait `std::error::Error` is not implemented for `()`
    |
    = note: required for the cast to the object type `dyn std::error::Error + std::marker::Send`

Seems related to rust-lang/rust#66757; we'll see if this can get unbroken on the compiler's side. But in the meantime changing the impl to the following would work on any compiler:

impl From<string::ParseError> for Error {
    fn from(e: string::ParseError) -> Self {
        match e {}
    }
}

[svartalf]

Hey, @dtolnay, thanks for a notice with this thing, I was wondering if it is a nightly or my own bug; for now I'm okay with failing nightly, so I'll leave it as is (let's leave the issue opened too in case if anyone will wonder about this).

Do not hesitate to ask if you will need any help from my side on this!

[sagis-tikal]

Seems to also happen when trying to compile Nushell 0.6.0.

[svartalf]

Upstream bug seems to be handled a bit slower than I expected, and since this issue is affecting downstream packages, I'm going to use the workaround suggested.

Thanks once again, @dtolnay!