eyre-rs / eyre

A trait object based error handling type for easy idiomatic error handling and reporting in Rust applications
Apache License 2.0
1.41k stars 68 forks source link

Allow use under miri (aka: fix UB / update `Error` impl to contain some of `anyhow`'s bugfixes since Jan) #59

Closed thomcc closed 1 year ago

thomcc commented 3 years ago

I'd like to move to using eyre over anyhow more. One downside is that eyre doesn't have the changes that make anyhow pass under miri, which means if I use eyre, much of it needs to be excluded from miri.

Also, there's at least case where the old code was UB in a way that the mutable noalias addition can exploit in theory (although in practice I suspect it would be very difficult). Fixing that requires most of the work to fix the other things, and in general

See https://github.com/dtolnay/anyhow/pull/134 for the original PR to anyhow (which I wrote, for essentially the same reason that I'd like this fixed in eyre), which talks about explicitly which patterns are bad, and gives some background.

In general the TL;DR is "doing dodgy things to &T, &mut T, Box<T>[^1] is very bad, so you need to use raw pointers". A concrete example is that stuff like ErrorImpl<()> pretty much needs to be held only behind a raw pointer. Instead of using an &ErrorImpl<()> to get at the fields, you need to eitehr use core::ptr::addr_of!/addr_of_mut!, or convert to *const ErrorImpl<E> which can be derefed. There are several other things like this, which are discussed in that PR.

[^1]: Including ManuallyDrop<Box<T>>

The ergonomics of that PR are quite bad, but it got up cleaned it up significantly by introducing https://github.com/dtolnay/anyhow/blob/master/src/ptr.rs afterwards.

These basically just give NonNull more semantic meaning, and making deref/deref_mut unsafe (even though it probably should explain when it's safe to use it (rarely) and erm, use the correct bounds for Send/Sync 😓)

I'm willing to do the work to make this happen, but... realistically it's probably going to make the code more complex and harder to maintain[^2], so I figured I'd give a heads up first.

[^2]: I wish this weren't the case, but the ergonomics of raw pointers are pretty awful across the board :(

yaahc commented 3 years ago

I'm willing to do the work to make this happen, but... realistically it's probably going to make the code more complex and harder to maintain2, so I figured I'd give a heads up first.

That's perfectly okay. Any help on getting the fixes implemented would be immensely appreciated.

ten3roberts commented 1 year ago

Working on this right now :smiley:

Got it mostly passing, but will need to set up CI testing as well