You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
rust-lang/miri#3341 provides an interesting example of a custom per-Box allocator that is incompatible with having noalias at the Box pointer. The problem is that the allocator uses offsets from the data pointer passed to deallocate to access allocator state, but this means when two Box<T, &MyAlloc> are passed to a function and dropped in that function, then the allocator state is accessed through these two separate data pointers, which are both noalias, so that's an aliasing violation. My impression is that allocators are allowed to do that kind of stuff, so the noalias has to go when a Box uses a custom allocator -- but that should be clarified.
For global allocators, deallocation is a compiler-understood "magic" operation, so there's a chance we can make this work. It has to be magic anyway since allocation is already magic. But custom per-Box allocators are just regular function calls so there's no such magic. (I guess an alternative to dropping noalias would be to make them more magic. Not sure if anyone wants that.)
Opening this here so this is answered definitely before stabilization. In particular there should be a proper decision on whether such code should be UB or not.
The text was updated successfully, but these errors were encountered:
rust-lang/miri#3341 provides an interesting example of a custom per-Box allocator that is incompatible with having
noalias
at the Box pointer. The problem is that the allocator uses offsets from the data pointer passed todeallocate
to access allocator state, but this means when twoBox<T, &MyAlloc>
are passed to a function and dropped in that function, then the allocator state is accessed through these two separate data pointers, which are bothnoalias
, so that's an aliasing violation. My impression is that allocators are allowed to do that kind of stuff, so thenoalias
has to go when aBox
uses a custom allocator -- but that should be clarified.For global allocators, deallocation is a compiler-understood "magic" operation, so there's a chance we can make this work. It has to be magic anyway since allocation is already magic. But custom per-Box allocators are just regular function calls so there's no such magic. (I guess an alternative to dropping
noalias
would be to make them more magic. Not sure if anyone wants that.)Opening this here so this is answered definitely before stabilization. In particular there should be a proper decision on whether such code should be UB or not.
The text was updated successfully, but these errors were encountered: