Permissive Borrows

language design Unsafe Code Guidelines
21

I did. (Last time I looked at it I was surprised that it didn't link to the LLVM RFC on an allocator provenance model, but I see you've added the link now and saved me the trouble of remembering where it was.)

I can definitely agree that having an explicit end-of-allocation signal makes things much easier. (In fact, most of the difficulty in defining an aliasing model happens because &mut doesn't have a usable explicit end-of-borrow signal.) I was so used to trying to design aliasing models around it not existing that I forgot that it might be viable for Box.

There is the potentially problematic case of Boxes that are in a leaked state (i.e. allocations that have not been deallocated) at the time the allocator's lifetime ends, which I think a "SB/TB + allocation end signal" provenance model could handle by falling back to the rules for &mut in such cases, but which is currently undecided in the LLVM proposal.

22

Yeah that part is a bit more speculative. I think we can just say that when an allocation is freed, all it's "child allocations" (that were created from parts of this allocation) are also freed. But without actually implementing that it's hard to predict whether there will be any issues with that.