Repository navigation
Compiling lambda_runtime_errors v0.1.1 ERROR #175
Description
Hello,
When compiling my project that uses:
lambda_runtime = "^0.2"
rusoto_core = "^0.42"
I get 2 errors when compiling lambda_runtime_error v0.1.1:
-
error[E0277]: the trait bound (): LambdaErrorExt is not satisfied-->$HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/lambda_runtime_errors-0.1.1/src/error_ext_impl.rs:145:9 -
error[E0277]: the trait bound(): std::error::Erroris not satisfied-->
$HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/lambda_runtime_errors-0.1.1/src/error_ext_impl.rs:145:9
Cargo version: cargo 1.41.0-nightly (8280633db 2019-11-11)
Rustc : rustc 1.41.0-nightly (412f43ac5 2019-11-24)
It seems that it is related to the nightly version since it worked perfectly 3 days ago and doesn't work since I run rustup update.
Activity
davidbarsky commentedon Nov 26, 2019
Hrm, thanks for the report. That's... not great. I'm not 100% sure what the cause is, but I think this relates to
!being stabilized around that time. As a result, type inference for()and!changed, resulting in the error you're seeing.That being said, we should be able to dump the
lambda_runtime_errorcrate now. If you'd like to send a PR removing it (and replace error reporting viastd::any::type_name), I'd gladly accept the PR. I don't think the error type in a Lambda function needs to be constrained to anything now—it can just be an unboundedE.jmendes92 commentedon Nov 28, 2019
Thanks for your feedback.
Until the end of the year, I haven't the time to do it. I'm doing my Master Thesis which is extremely time-consuming. If someone else could fix it, until then, it would be great. Otherwise, I will look into it, in January.
fixes aws#175
tsal commentedon Jan 2, 2020
I'm not sure if it's related, but this seems to no longer fail (it did for me when I checked a month ago). Even without #182 being merged.
Granted, I'm not using the
lambda_runtime_errorcrate.davidbarsky commentedon Jan 3, 2020
@tsal missed that fix, oops. the stabilization of
!got reverted, so this issue can probably be closed.jmendes92 commentedon Jan 9, 2020
I modified my implementation so I can use the
stabletoolchain instead. I tried to compile with thenightly (cargo 1.42.0-nightly (6e1ca924a 2020-01-06))toolchain and it worked too.So as suggested by @davidbarsky I closed the issue.