3 ms·

> Sadly, Rust doesn't do this by default due to problems with LLVM, but eventually it can. Can it, though? I keep hearing/reading FUD around both unsafe and Pi

> Sadly, Rust doesn't do this by default due to problems with LLVM, but eventually it can. Can it, though? I keep hearing/reading FUD around both unsafe and Pin making it unlikely to ever be able to ubiquitously enable the noalias stuff.

Jweb_Guru 6y ago
Code affected by unsafe already has to go through `UnsafeCell` which disables most aliasing optimizations, and the stacked borrow semantics have explicit opt-outs for such cases. I don't believe there are any Rust semantic issues standing in the way of exploiting aliasing information in this way, just LLVM bugs (and the fact that its restrict model isn't currently equipped to handle the information at such a fine granularity).
- nyanpasu64 6y ago
  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.
kibwen 6y ago
You have correctly identified it as FUD. People have a bone to pick with Pin, so they irrationally latch on to it, but the general problem is the fact that the &mut invariants cannot currently permit any self-referential data, which is a useful concept in general (for intrusive data structures, etc) and whose lack that people have been hacking around since before 1.0, with crates like rental and owning_ref. The plan to fix this is to make self-referentiality a first-class concept in the language, as a principled exception to the usual &mut uniqueness invariant that preserves memory safety while properly encoding the aliasing guarantees.
- ameliaquining 6y ago
  Source? I would like this to be true, but I haven't actually seen it anywhere.
  - steveklabnik 6y ago
    https://news.ycombinator.com/item?id=26410487 https://news.ycombinator.com/item?id=26410487 (it's a significant part, though not the entirety, of this comment)
  - kibwen 6y ago
    Here's Niko Matsakis' take: https://github.com/rust-lang/rust/issues/63818#issuecomment-526579977 https://github.com/rust-lang/rust/issues/63818#issuecomment-...
- dataangel 6y ago
  > The plan to fix this is to make self-referentiality a first-class concept in the language, as a principled exception to the usual &mut uniqueness invariant that preserves memory safety while properly encoding the aliasing guarantees. Are there issues I can subscribe to or RFCs for this?
  - kibwen 6y ago
    Yep, this one: https://github.com/rust-lang/rust/issues/63818 https://github.com/rust-lang/rust/issues/63818 (the comment I'm summarizing is https://github.com/rust-lang/rust/issues/63818#issuecomment-526579977 https://github.com/rust-lang/rust/issues/63818#issuecomment-... )
kimundi 6y ago
The github discussion thread where that originates from also contain the language designers optimistically discussing how in the worst case `Pin` just has to be hardcoded to exclude these optimizations. Which wouldn't make it the first type in the std lib that works similary (see interior mutability and UnsafeCell), so I personally intepret that as "unlikely to be an issue".

Jweb_Guru 6y ago

Code affected by unsafe already has to go through `UnsafeCell` which disables most aliasing optimizations, and the stacked borrow semantics have explicit opt-outs for such cases. I don't believe there are any Rust semantic issues standing in the way of exploiting aliasing information in this way, just LLVM bugs (and the fact that its restrict model isn't currently equipped to handle the information at such a fine granularity).

nyanpasu64 6y ago
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.

kibwen 6y ago

You have correctly identified it as FUD. People have a bone to pick with Pin, so they irrationally latch on to it, but the general problem is the fact that the &mut invariants cannot currently permit any self-referential data, which is a useful concept in general (for intrusive data structures, etc) and whose lack that people have been hacking around since before 1.0, with crates like rental and owning_ref. The plan to fix this is to make self-referentiality a first-class concept in the language, as a principled exception to the usual &mut uniqueness invariant that preserves memory safety while properly encoding the aliasing guarantees.

ameliaquining 6y ago
Source? I would like this to be true, but I haven't actually seen it anywhere.
- steveklabnik 6y ago
  https://news.ycombinator.com/item?id=26410487 https://news.ycombinator.com/item?id=26410487 (it's a significant part, though not the entirety, of this comment)
- kibwen 6y ago
  Here's Niko Matsakis' take: https://github.com/rust-lang/rust/issues/63818#issuecomment-526579977 https://github.com/rust-lang/rust/issues/63818#issuecomment-...
dataangel 6y ago
> The plan to fix this is to make self-referentiality a first-class concept in the language, as a principled exception to the usual &mut uniqueness invariant that preserves memory safety while properly encoding the aliasing guarantees. Are there issues I can subscribe to or RFCs for this?
- kibwen 6y ago
  Yep, this one: https://github.com/rust-lang/rust/issues/63818 https://github.com/rust-lang/rust/issues/63818 (the comment I'm summarizing is https://github.com/rust-lang/rust/issues/63818#issuecomment-526579977 https://github.com/rust-lang/rust/issues/63818#issuecomment-... )

kimundi 6y ago

The github discussion thread where that originates from also contain the language designers optimistically discussing how in the worst case `Pin` just has to be hardcoded to exclude these optimizations. Which wouldn't make it the first type in the std lib that works similary (see interior mutability and UnsafeCell), so I personally intepret that as "unlikely to be an issue".