Note that this intentionally doesn't migrate cranelift-faerie,because faerie uses failure::Error in its public API. We can migrate cranelift-faerie if and when faerie itself switches over, or we can not worry about it if all its users switch to cranelift-object instead.

Thanks for opening a PR! However, this is typically the kind of PRs that would benefit from filling in the PR template, and even opening an issue to discuss alternatives and consider whether this is something we'd like to do.

In particular, there are other crates that also handle errors, and it'd be nice to get some pros/cons for each of them. Also, changing dependencies in cranelift-codegen is a bit sensitive because it has an impact for embedders using (cargo) vendoring (I'm thinking about Firefox's code base, which already includes failure but not thiserror).

Code looks great and I'm very happy to see the manual From implementations disappear, though. It would be nice to compare against alternative implementations, though.

@bnjbvr I did discuss and coordinate this with @sunfishcode before submitting it, and filed an issue at bytecodealliance/wasmtime#436 to discuss as well before starting this work.

A bit more on thiserror vs failure:

thiserror has fewer dependencies than failure_derive. thiserror uses the standard std::error::Error type (whereas failure invents its own Fail type), so it smoothly integrates with other users of Error. It also carefully avoids exposing any implementation details of itself in the public API; error types derived using thiserror have the same API that you would get if you wrote them by hand.

Thus, I'd suggest that thiserror has the minimum possible impact on users of cranelift. I hope that there's no further churn in error-handling conventions in the community, but on the off chance there is, I think that it'd be entirely transparent to the users of cranelift, and could be done without in any way breaking the cranelift ABI.

I wasn't aware of the wasmtime issue, fair enough. That being said, this doesn't tell anything about other crates implementing the same behavior. In particular, it seems err-derive is in the same tarball's size ball park, and also has no-std support, which would be nice to ~maintain in Cranelift. (error_chain that's mentioned in this crate's readme, seems to serve a different purpose.)

err-derive's approach to no_std support is to not derive Error, and only support From and Display.

thiserror has fewer dependencies than either err-derive or failure_derive.

thiserror does have plans to handle no_std through a common "core error" trait; see dtolnay/anyhow#9 for details.

Thanks for the review and the merge, @bnjbvr and @sunfishcode!

A quick note: sorry for not using the pull request template for this PR. I didn't see it, as I don't typically submit pull requests via the github web interface. I use git-hub, and just type git hub pull new to create a new pull request. I've filed sociomantic-tsunami/git-hub#273 asking git-hub to respect pull request templates.

Thanks again for your patience and review.

I use git-hub

Ah, that explains the lack of context here. Your answers definitely cleared up all my questions, so I appreciate you taking the time providing them.