Closed thomcc closed 1 year 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.
Working on this right now :smiley:
Got it mostly passing, but will need to set up CI testing as well
I'd like to move to using
eyre
overanyhow
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 likeErrorImpl<()>
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 usecore::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 :(