Stabilizing the Allocator API

Docs say nothing about pinning: If you allocate and then drop the allocator without calling deallocate, can the allocator free the underlying memory?

Amanieu: The answer is yes

So you can't allocate pinned objects, unless the allocator is 'static. If it's 'static we require (somewhere) that the memory must retain its validity.

Taylor: No, docs say that you can drop the allocation when the allocator is dropped…

Amanieu: the allocator itself must be static, but the lifetime to the allocator does not have to be

Memory blocks that are currently allocated by an allocator, must point to valid memory, and retain their validity while until either:

• the memory block is deallocated, or
• the allocator is dropped.

struct Alloc {} // ?
let something = ..;
let alloc = ..;
let boxed = Box::new_in(something, alloc);
let pinboxed: Pin<Box<T, Alloc>> = Box::into_pin(boxed);
// ?
Box::leak(pinboxed)

Amanieu: it's a bug that Box::leak does not leak the allocator. That's unsound.

• (Later follow-up, it's not actually unsound, just that the code isn't very explicit. Fixed by https://github.com/rust-lang/rust/pull/141219)

Taylor: Box::into_pin, what happens if you leak that?

the8472: this is ok because the destructor is never called, and so the allocator never deallocates.

Taylor: I'd like stack-based allocators to be able to hold pinned objects.

the8472: RFC to allow overlapping marker trait implementations is already implemented? Would allow a marker trait rather than the static bound.

Allocator::grow is very poorly specified

• when can you return an error? alignment problems only or also out-of-memory problems?
• people will treat any error as OOM, probably

What is the API benefit of having separate grow/shrink methods?

• Amanieu: Usually entirely different codepaths in allocators.

async hardware allocations???

Grow improvements:

• Don't allow? changing layout parts of layout like alignment, only size
• Take initializated size as arg
• grow_in_place requires StorageResized – check with Ralf
  • Should we allow StorageLive on a live local

Dealloc trait

https://github.com/rust-lang/wg-allocators/issues/112

Grow and alignment-changing

• there's benefits to being able to do it like taking Vec<T>'s allocation and reusing it for a Vec<U>
• but also it's a horrid pain to actually do in practice so lots of allocators want to be able to opt out

cross-allocator cloning

• we impl FromIterator only for GlobalAlloc?
  • because of inference issues.
  • defaults affect inference! defaults affect inference! defaults affect inference!

string allocator param???

• associated constants???
• cannot create a path to assoc constants because you need to specify the generics???

Allocations optimized away

• Only for Global
• Do we want it to apply to other allocators?
• Some allocator implementers don't want it to!
• Provenance???!?
  • hypothetical intrinsic that mints a new provenance???
  • does provenance even make sense inside an allocator?
  • What does LLVM need to detect this? Sounds like it is currently a very specific signature that probably doesn't match what we have.

Support zero-sized allocation

Better let the caller handle it. Make it UB so allocator doesn't need to.

• If the allocator must allow ZSTs, then it's allocator-dependent whether things "just work" or if it needs some kind of check
• Amanieu: simplicity for the caller is a reason we would want the allocator to handle the check/behavior
• NonZeroLayout would be nice
• Easier to optimize out ZST checks on the caller side

tg: this issue is worth a read, it has some more concrete proposals that seem to approximately mirror the consensus in the meeting https://github.com/rust-lang/rust/issues/32838#issuecomment-2760323045