3 ms·

There is undefined behavior in Rust affecting real-world code, including Tokio's scheduler, and code produced by async fn definitions. UnsafeCell doesn't solve

There is undefined behavior in Rust affecting real-world code, including Tokio's scheduler, and code produced by async fn definitions. UnsafeCell doesn't solve the problem. There's more information at https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a42462 https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a.... Bug report at https://github.com/rust-lang/rust/issues/63818 https://github.com/rust-lang/rust/issues/63818. Reddit threads at (older) https://www.reddit.com/r/rust/comments/l4roqk/a_fix_for_the_llvm_noalias_bug_has_landed_in_time/gkq8wvg/ https://www.reddit.com/r/rust/comments/l4roqk/a_fix_for_the_... and (newer) https://www.reddit.com/r/rust/comments/lxw6cl/update_to_llvm_12_got_merged/gppvcy5/ https://www.reddit.com/r/rust/comments/lxw6cl/update_to_llvm.... Somewhat related HN thread at https://news.ycombinator.com/item?id=26406989 https://news.ycombinator.com/item?id=26406989.

Jweb_Guru 6y ago
This is the `Pin<&mut>` example which I'm not that familiar with but was aware of. I think it's highly unlikely that this one, relatively niche use case is going to prevent Rust from ever being able to safely turn on aliasing optimizations. There have been several solutions proposed, e.g. adding a stricter UnsafeCell to the language; they may technically not be backwards-compatible, but given how `Pin` is used and the fact that this is a soundness issue, I think it should be fine. The HN thread is mostly unrelated. I agree that it would have been better to integrate `Pin` directly into the language, though, but mostly for ergonomic reasons; it could still probably happen in an edition upgrade.