https://github.com/rust-lang/miri/issues/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.
https://github.com/rust-lang/miri/issues/3341 provides an interesting example of a custom per-Box allocator that is incompatible with having
noaliasat the Box pointer. The problem is that the allocator uses offsets from the data pointer passed todeallocateto 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 thenoaliashas to go when aBoxuses 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
noaliaswould 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.